REMARKS 



I. Summary 

In response to the office action dated October 17, 2005, the applicants traverse the 102 (e) 
rejections based upon US Patent No. 5,256,863 to Ferguson et al. ("Ferguson") because the 
Ferguson reference relied upon by the examiner, is not prior art under 102 (e) for the following 
reasons. 

Applicants submit that a patent granted on an application for patent by another filed in the 
United States before the invention by the applicant constitutes prior under 102 (e) if the 
application describes the invention before the invention by the applicant for patent. 35 USC 102 
(e) (2). Since Ferguson does not claim priority to any other applications, Ferguson's filing date is 
November 5, 1991. See Ferguson patent 5,256,863 item 22 (Attachment 1). Thus, Ferguson's 
102 (e) prior art date is November 5, 1991., 

This application, however, claims priority to application Serial No. 07/345,475, filed May 

I, 1989 by David W. Deaton and Robert S. Wood entitled "Check Transaction Processing 
Method and System." This application and all intervening applications in the chain of priority to 
07/345,475 have the same disclosure. May 1, 1989 is two years and six months prior to the 
November 5, 1991 priority date of the Ferguson patent. Thus, Ferguson is not a prior art 
reference. In order to support the applicants' assertion that this application is entitled to claim 
benefit to the May 1, 1989 filing date of the 07/345,475 application, and that all applications in 
the priority chain have the same disclosure, the applicants provide and cite to the following 
evidence. 

II. Evidence 



Attachment 2 is a copy of (1) a request for filing a 37 CFR 1.60 continuation application 
of pending US Application Serial No. 08/117,951 and (2) a certificate of express mailing, having 
a mail date of September 22, 1997. Attachment 2 is the paper record in applicant's file for this 
application, 08/935,1 16, filed on 9/22/1997. 



Attachment 2: Request for Filing Continuation Application Under 37 CFR 1.60 
Filed- 9/22/1997 (which is this 08/935,116 application) 
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Attachment 2, page 3 shows the applicants amended the specification of 08/935,116 by 
inserting a paragraph "Cross Reference to Related Applications." In that paragraph the applicants 
claimed that this application was a continuation of 08/1 17,951, filed August 30, 1993, which was 
a continuation of application 07/826,255 filed January 24, 1992, and which was a continuation of 
application 07/345,475 filed May 1 , 1989. 

Attachment 3: Request For Corrected Official Filing Receipt- Filed 08/10/1998 in 
08/935,116 

Attachment 3 is a copy of request for a corrected USPTO filing receipt filed on 
08/10/1998 - a paper record in applicant's file for application 08/935,1 16, filed on 9/22/1997. 
Attachment 3 page 3 shows that the applicants had notified the USPTO that the priority data was 
incorrectly entered into the USPTO records and had requested the USPTO to correct the priority 
data to application 07/345,475 filed on May 1, 1989. 

Attachment 4: Request For Corrected Official Filing Receipt- Filed 06/1 1/2002 in 
08/935,116 

Attachment 4 is a copy of request for corrected official filing receipt filed on 6/1 1/2002 - 
a paper record in applicant's file for application 08/935,1 16, filed on 9/22/1997. Pages 3-5 show 
that the applicants notified the USPTO regrading the omission of the domestic priority 
information. Thus, this request shows that the applicants had notified the USPTO of the missing 
priority claim and requested the USPTO to enter the correct priority claim into the USPTO 
records. 

Attachment 5: Request For Corrected Official Filing Receipt- Filed 12/08/2004 in 
08/935,116 

Attachment 5 is a copy of request for an official corrected filing receipt filed on 12/08/ 
2004 - a paper record in applicant's file for application 08/935,1 16, filed on 9/22/1997. Page 4 
shows that the applicants had notified the USPTO about the incorrect USPTO filing receipt. 
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Attachment 6: Portions of photocopies of the official file history for 07/345,475 
including its disclosure, as filed, statement claiming small entity status, certificate of mailing and 
transmittal, all stamped by the USPTO with the date May 1, 1989 and the application number 
07/345,475. Attachment 6 shows that the disclosure of 07/345,475 is the same as the disclosure 
of the 08/935,1 16 application. 

III. Analysis 

Attachments 2-5 show that on four separate occasions, the applicants had 
requested the USPTO to correct and enter the domestic priority claim to application 07/345,475 
filed on May 1, 1989, into the specification of the pending application 08/935,116. Apparently, 
the USPTO failed to enter the corrected priority claim into the USPTO record. The fact that 
USPTO records may fail to reflect that is office error, and legally irrelevant to what constitutes 
legal prior art under 35 USC 102(e). 

Application 08/935,116 is therefore one in a chain continuations of application 07/345,475 
because all have the same substantive disclosure. The applicants' properly claimed continuity to 
May 1, 1989. A comparison of the disclosure in attachment 6 with the disclosure in this 
application shows them to be substantively identical. 

Since this application is clearly entitled to the benefit of the filing date of May 1, 1989, 
US Patent 5,256,863 to Ferguson et al. is not a prior art reference under 102 (e). Therefore, the 
rejections based upon Ferguson of claims 8-16 are improper and should be withdrawn. 
Accordingly, claims 8-16 should be held allowable. 




Registration No. 35, 299 
Attorney of record 
Laba Karki 

Registration No. 55,317 
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Printed: November 29, 2005 (11:51am) 

Y:\Clients\Catalina\DEATON-18\DEATON-18-US-Cl\DraftsVResponseToOfficeAction_051 
125.wpd 
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LIST OF ATTACHMENTS 1-6 



Attachment 1: Copy of First Page of Ferguson patent 5,256,863 

Attachment 2: Copy of Request for Filing Continuation Application Under 37 CFR 1.60 Filed- 
9/22/1997 

Attachment 3: Copy of Request For Corrected Official Filing Receipt- Filed 08/10/1998 

Attachment 4: Copy of Request For Corrected Official Filing Receipt- Filed 06/1 1/2002 

Attachment 5: Copy of Request For Corrected Official Filing Receipt- Filed 12/08/2004 

Attachment 6: Portions of photocopies of the official file history for 07/345,475 including its 
disclosure, as filed, statement claiming small entity status, certificate of mailing 
and transmittal, all stamped by the USPTO with the date May 1, 1989 and the 
application number 07/345 ,475 . 
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December 7, 2005 (11:30am) 
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UNITED STATES PATENT AND TRADEMARK OFFICE ■ 



In re application of: 
DAVID W. DEATON, et al . 

For: CHECK TRANSACTION PROCESSING METHOD AND SYSTEM 

Anticipated Classification of 
this Application: 
Class: , Subclass: 



Prior Application: 



Serial No. 
Filed: 
Examiner : 
Group : 



08/117, 951 
August 30, 1993 
Kuong Chung -Trans 
2311 



Honorable Commissioner of 

Patents and Trademarks 
Washington, D.C. 20231 



is being <fcfHpisittS with = the .Utut$d. States ; ; . 
Postal /^Semce? "^^l^^ail-v^Ppstv 1 




Name : 



.Eiq^ress;MaiI CerL : :Nb^ 



REQUEST FOR FILING CONTINUATION APPLICATION . 
UNDER 37 C .F.R. S 1-60 
This is a request for filing a continuation 
application under 37 C.F.R. § 1.60 of pending U.S. 
Application Serial No. 08/117,951, filed on August 30, 
1993, for "Check Transaction Processing Method and System," 
by the following named inventors: 



DALOU: 329264.1 
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Name: DAVID W. DEATON 

Address: 922 Ruswood Circle 

. Abilene, Texas 79601 

Citizenship: U.S.A. 

Name: ROBERT S. WOOD 

Address: 902 Pardoners Road 

Abilene, Texas 79602 

Citizenship: U.S.A. 



Enclosed is a copy of the prior application, including 
the Declaration and Power of Attorney, as filed in the 
prior application. 

I hereby verify that the attached papers are a true 
copy of prior Application Serial No. 08/117,951 as 
originally filed on August 30, 1993, and further that this 
statement was made with the knowledge that willful false 
statements and the like so made are punishable by fine or 
imprisonment, or both, under Section 1001 of Title 18 of 
the United States Code and that such willful false 
statements may jeopardize the validity of the application 
or any patent issuing thereon. 

The filing fee is calculated below: 

CLAIMS AS FILED IN THE PRIOR APPLICATION, 
LESS ANY CLAIMS CANCELLED BY AMENDMENT BELOW 
OR ADDED BY PRELIMINARY AMENDMENT 

For Number Extra Rate Fee 

Filed 

Basic Fee $385.00 

Total 

Claims 4 -20 = 0 x $11 = $000.00 

Independent 

Claims 4 -3 = 1 x $40 = $ 40.00 
TOTAL FILING FEE $425.00 - 
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1. Enclosed is a check in the amount of $425.00 in 
payment of the filing fee. The Commissioner is hereby 
authorized to charge any fees which may be required, or 
credit any overpayment, to Deposit Account No. 02-03 84 of 
Baker & Botts, L.L.P. A duplicate copy of this paper is 
enclosed. 

■J 

2. Cancel in this application original Claims 2-7, 



leaving Claim 1 to prosecute in this application, before 
calculating the filing fee. 

3 . Amend thp Specification by inserting the 

following at Page ir, line 1; . 

- - - CROSS REFERENCE TO RELATED APPLICATIONS 

This application is a continuation of pending U.S. 
Application Serial No. 08/117,951 filed. August 30, 1993 by 
David W. Deaton and Robert S. Wood entitled "Check 
Transaction Processing Method and System," pending; which 
is a continuation of U.S. Application Serial No. 07/82 6,255 
filed January 24, 1992 by David W. Deaton and Robert S. 
Wood entitled "Check Transaction Processing Method and 
System," abandoned; which is a continuation of U.S. 
Application Serial No. 07/345,475 filed May 1, 1989 by 
David W. Deaton and Robert S. Wood entitled "Check 
Transaction Processing Method and System," abandoned. 

This application is related to U.S. Patent No. 
5,201,010 issued April 6, 1993 entitled "Method and System 
for Building a Database and Performing Marketing Based upon 
Prior Shopping History"; U.S. Patent No. 5,237,620 issued 
August 17, 1993 entitled "Check Reader Method and System 
for Reading Check MICR Code"; U.S. Patent No. 5,305,196 
issued April 19, 1994 entitled "Check Transaction 
Processing, Database Building and Marketing Method and 
System Utilizing Automatic Check Reading"; U.S. Patent No. 
5,327,508 issued July 5, 1994 entitled "Method and System 
for Building a Database and Performing Marketing Based upon 
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Prior Shopping History"; U.S. Patent No. 5,388,165 issued 
February 7, 1995 entitled "Method and System for Building 
a Database and Performing Marketing Based upon Prior 
Shopping History"; U.S. Patent No. 5,430,644 issued July 4, 
1995 entitled "Check Transaction Processing, Database 
Building and Marketing Method and System Utilizing 
Automatic Check Reading"; U.S. Patent No. 5,448,471 issued 
September 5, 1995 entitled "Check Transaction Processing, 
Database Building and Marketing Method and System Utilizing 
Automatic Check Reading"; U.S. Patent No. 5,592,560 issued 
January 7, 1997 entitled "Method and System for Building a 
Database and Performing Marketing Based upon Prior Shopping 
History"; U.S. Patent No. 5,621,812 issued April 15, 1997 
entitled "Method and System for Building a Database for use 
with Selective Incentive Marketing in Response to Customer 
Shopping Histories" ; U.S. Patent No. 5,638,457 issued .June 
10, .1997 entitled "Method and System for Building a 
Database for use with Selective Incentive Marketing in 
Response to Customer Shopping Histories"; U.S. Patent -No. 
5,642,485 issued June 24, 1997 entitled "Method and System 
for Selective Incentive Point -of -Sale Marketing in Response 
to Customer Shopping Histories"; U.S. Patent No. 5,644,723 
issued July 1, 1997 entitled "Method and System for 
Selective Incentive Point -of -Sale Marketing in Response to 
Customer Shopping Histories"; U.S. Patent No. 5,649,114 
issued July 15, 1997 entitled "Method and System for 
Selective Incentive Point-of -Sale Marketing in Response to 
Customer Shopping Histories"; U.S. Patent No. 5,659,469 
issued August 19, 1997 entitled "Check Transaction 
Processing, Database Building and Marketing Method and 
System Utilizing Automatic Check Reading"; U.S. Application 
Serial No. 08/096,921 filed July 23, 1993 entitled "Method 
and System for Selective Incentive Point-of -Sale Marketing 
in Response to Customer Shopping Histories"; U.S. 
Application Serial No. 08/302,521 filed September 6, 1994 
entitled "Method and System for Building a Database for use 
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with Selective Incentive Marketing in Response to Customer ^f^n-' 
Shopping Histories" ; U.S. Application Serial No. 08/457,300 U ^' A 
filed June l f 1995 entitled "Method and System 'for 
Selective Incentive Point-of -Sale Marketing in Response to 
Customer Shopping Histories"; U. S. Application Serial No. 
08/701,456 filed August 22, 1996 entitled "Check 
Transaction Processing, Database Building and Marketing 
Method and System Utilizing Automatic Check Reading"; U.S. 
Application Serial No. 08/734,675 filed October 21, 1996 
entitled "Method and System for Selective Incentive Point - 
of-Sale Marketing in Response to Customer Shopping 
^ Histories"; U.S. Application Serial No. 08/820,020 filed 
March 12, 1997 entitled "Method and System for Selective 
Incentive Point-of -Sale Marketing in Response to Customer 
Shopping Histories"; U.S. Application Serial No. 08/815,756 
filed March 12, 1997 entitled "Method and System for 
Selective Incentive Point-of -Sale Marketing in Response to 
Customer Shopping Histories: U.S. Application Serial :No. 
08/896,840 filed July 18, 1997 entitled "Method and System 
for Building a Database for use with Selective Incentive 
Marketing in Response to Customer Shopping Histories" . -- 

4. Informal drawings are enclosed herewith. 

5. A Letter to the Office Draftsman is enclosed. 

6. A Preliminary Amendment is enclosed. 

7. A Verified Statement Claiming Small Entity Status 
is enclosed. 



8. The prior application is assigned of record to 
CREDIT VERIFICATION CORPORATION, a Texas corporation, at 
reel 5123, frame 0680 in the U.S. Patent and Trademark 
Office records, and was recorded on July 3, 1989. 
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9. 



The Power of Attorney in the prior application is 



to: 



Jerry W. Mills, Reg. No. 23,005 



Robert M. Chiaviello, Jr., Reg. No. 32,461 
The power appears in the original papers in the prior 
application. 

10. An Appointment of Associate Attorneys is 
enclosed. 

11. Please address all future communications to: 
Jerry W. Mills, Esq. 

BAKER & BOTTS, L.L.P. 
2001 Ross Avenue 
Dallas, Texas 75201-2980 
214/953-6665 

Early and favorable acceptance of this continuation 
application is respectfully requested. 



CWK:bkd 

2001 Ross Avenue 
Dallas, Texas 75201-2916 
(214) 953-6812 
Date: September 22, 1997 



Respectfully submitted, 
BAKER & BOTTS, L.L.P. 
Attorneys for Applicant 




Christopher W. Kennerly 
Registration No. 40,675 
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ATTORNEY DOCKEi NUMBER 
026656.0238 



PATENT 
08/935,116 



IN THE 

In re Application of: 
Serial No.: 
Filing Date: 
Title: 



UNITED STATES PATENT AND TRADEMARK OFFICE 

David W. Deaton et al. 
08/935,116 
September 22, 1997 

Check Transaction Processing Method and System 



I 



Application Processing Division 
Customer Correction Branch 
Assistant Commissioner of Patents 
Washington, D.C. 20231 



l hereby certify that this 
COTiespraidence is being deposited with 
the United States Postal Service as first 
class mail in an envelope addressed 
to: Application Processing Division, 
Customer Correction Branch, Assistant 
Commissior^ of Patera, Washington, 
D.C. 20231, on the date shown below. 



Name 



Date 



Dear Sir: 



rrr . TT r F ™ muBEtnTP OFFi nftT FIT ilNO RECE1H 
A ^Uacopyof*cOf fi ci» 1 FUi n gRec«pt K ceiv«d fto mU,.U.S.P»«»tand 

filing receipt is respectfully requested. . n4 vlDW 
n.efflingreceip.has^nea^nameofu.esecondAppbcan.. After DAVID W. 

DEATON, ABILENE, TXT please insert —ROBERT S. WOOD, ABILENE, TX- 

CON OF 08/1 17,95 1 08/30/93" please insert the following: 
—WHICH IS A CON OF 07/826,255 01/24/92 ABN 

WHICH IS A CON OF 07/345,475 05/01/89 ABN—. 
Please refer to " CROSS-REFERENCE TO RELATED APPLICATION" on page 3 of the 
attached copy of the "Request for Filing Continuation Application." 
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ATTORNEY DOCKEi NUMBER 08/935,116 

026656.0238 

A corrected filing receipt is respectfully requested. 

While it isbelieved that this is not an error by the Applicants, the Commissioner ,s 
hereby authorized to charge any amount required or credit any overpayment to Deposn 
Account No. 02-0384 of Baker & Botts, L.L.P. 

Respectfully submitted this ±£L day of August, 1998. 

BAKER & BOTTS, L.L.P. 
Attorneys for Applicants 




Christopher W. Kennerly 
Reg. No. 40,675 



2001 Ross Avenue 
Dallas, Texas 75201-2916 

(214) 953-6812 

(kwl) 
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(R«v. 8-6) 
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CORRECTED 




UNITED STATES f^ARTMENT OF COMMERCE 
Patent and Trademark; Offica 
ASSISTANT SECRETARY AND COMMISSIONER 
OF PATENTS AND TRADEMARKS 
Washington. D.C. 20231 



BAKER AND BOTTS 
2001 ROSS AVENUE 
DALLAS TX 75201-2916 
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mult, of th. •xunh.tlon. B. mur. to provid. . AW ^]??1 "i^Toi draft iriiiubi»ct to coltactlon. H«m v«tfy th. "curacy 

INVENTION wh«n inqukfag .bout thb ^J^^L ^IL^-TpUS ^STto *• AppBorfon PmKUbig DM-oo'. 



AwBc,ntW DAVID W. DEATON, ABILENE/ TX. 



CONTINUING DATA AS CLAIMED BY APPLICANT- „ 

THIS APPLN IS A CON OF 08/117.95108 

FOREIGN FILING LICENSE GRANTED 01/29/98 
TITLE 

CHECK TRANSACTION PROCESSING_METHOD AND SYSTEM 



* SMALL ENTITY * 



PRELIMINARY CLASS: 705 



Baker & Botts, LLP . 
JUN18 1998 
RECEIVED 



Sheets 

pages 

□CPA 

□ Priority Doc 

□ Dep. Acct Order Form 



^ Dept: EE 

foMM*™ viu w >9Qi <»ffl isisvcqnt By: CLG/pmh w 
Serial No. ns/Qiyifi 

In the matter of the Application of: David W, ORATON, et al. 

For: SVSTRM , MKTH On AND DATARASF, FOR PROPRSSINCt 

transactions 

The following has been received in the U.S. Patent Office on the date stamped hereon: 

□ pp. Specification & Claims/Drawings 

□ Combined Declaration, Petition & Power of Attorney 

□ List of Inventor Names and Addresses 

□ Utility Patent Application 

□ Notice of Priority 

□ Check for 
D Fee Transmittal Form 
a Assignment/PTO 1595 pages: 

□ Letter to Official Draftsman 

□ Letter Requesting Approval of Drawing Changes 

□ Drawings sheets □ Formal 

□ Letter 

□ Amendment 

□ Information Disclosure Statement 
a Cited References ( ) 

□ Search Report 
a Statement of Relevancy 

□ IDS/Related/List of Related Cases 

□ Restriction Response 
o Rule 132 Declaration 

□ Petition for Extension of Time 

□ Notice of Appeal 

□ Brief 

□ Issue Fee Transmittal 
o White Advanced Serial Number Card 

■ Request for Corrected Official Filing Receipt 

■ Copy of Official Filing Receipt with Correction(s) 




□ Election Response 



DOCKET NUMBER: 201930US25XCONT/pmh 
TM TWF TTNTTED STATES PATENT A 




K OFFTCE 



IN RE APPLICATION OF: 
David W. DEATON, et al. 



: GROUP: 2162 



SERIAL NUMBER: 08/935,116 . 
FILED: SEPTEMBER 22, 1997 
FOR: SYSTEM, METHOD, AND DATABASE FOR PROCESSING TRANSACTIONS 



: ATTENTION: 
Application Division 
Customer Corrections 




REQUEST FOR CORRECTED OFFTC.TAT. FTTTNG RFCFTPT 



CI 

Vj" 



Assistant Commissioner for Patents t > 

Washington, D.C. 20231 g§ ^ 

~% m 

Sir: 3£ .'so O 

The Patent Office is requested to provide a corrected Official Filing ^eeeipj2fonth;e 
attached. No fees are required. If you have any questions, please do not hesiUtHo cfjntacfus. 

cr — 

Respectfully submitted, 

OBLON, SPIVAK, McCLELLAND, 
MAIER & NEUSTADT, P.C. 



(ml ^ AaM m/' 

Charles L. Gholz / 

Attorney of Record D FCEIVE D 

Registration Number 26,395 nUVU 

JUL 2 4 2002 

GROUP 3600 

Paul A. Sacher 
Registration No. 43,418 
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Tel. (703) 413-3000 
Fax. (703) 413-2220 
(OSMMN 10/98) 



Richard A. Neifeld, Esq. 
OBLON, SPJVAK, McCLELLAND, MAIER 
1755 Jefferson Davis Highway 
Crystal Square Five - Fourth Floor 
Arlington, VA 22202 



Receipt is acknowledged of a CPA in this nonprovisional Patent Application. It will be considered in its order and 
you will be notified as to the results of the examination. Be sure to provide the U.S. APPLICATION NUMBER, 
FILING DATE, NAME OF APPLICANT, and TITLE OF INVENTION when inquiring about this application. Fees 
transmitted by check or draft are subject to collection. Please verify the accuracy of the data presented on this 
receipt. If an error is noted on this Filing Receipt, please write to the Office of Initial Patent Examination's 
Customer Service Center. Please provide a copy of this Filing Receipt with the changes noted thereon. If 
you received a "Notice to File Missing Parts" for this application, please submit any corrections to this 
Filing Receipt with your reply to the Notice. When the USPTO processes the reply to the Notice, the 
USPTO will generate another Filing Receipt incorporating the requested corrections (if appropriate). 

Appltcant(s) 

DAVID W. DEATON, ABILENE, TX; 

Domestic Priority data as claimed by applicant 

THIS APPLICATION IS A CON OF 08/117,951 08/30/1993 ABN 

Foreign Applications 

If Required, Foreign Filing License Granted 01/29/1998 
CPA filed on: 08/28/2001 1 
Projected Publication Date: 02/28/2002 
Non-Publication Request: No 



^ CONFIRMATION NO. 8230 

CORRECTED FILING RECEIPT 




•OC000000007104756* 



Date Mailed: 11/21/2001 



RECEIVED 

JUL 2 * 2002 

GROUP 3600 



Early Publication Request: No Ifi^li^/Jii-i^'h : v / * 

"SMALL ENTITY" ,"»«^ *^fi(" ; 

^ KCV 2 6 200!'' 

FOR PROCESSING ^Sl^Sveml^lz^ 
Preliminary Class 
705 



Title 

SYSTEM, METHOD, AND DATABASE 



PLEASE NOTE THAT THE SECOND APPLICANT'S INFORMATION HAS BEEN 
OMITTED. IT SHOULD READ AS FOLLOWS: 

2ND= ROBERT SCOTT WOOD. ABTIFNE. TEXAS 

PLEASE NOTE THAT THE DOMESTIC PRIORITY INFORMATION IS INCORRECT. IT 
SHOULD READ AS FOLLOWS: 

THIS APPLICATION IS A CON OF 08/1 17,951 08/30/93 ABN 

WHTPH IS A CON OF MISM *>K 01/24/92 ABN /OC^JxC 

WHICH IS A CON OF MndK.d'K 03/01/89 ABN f (f 
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has the power to control the other, or a third party or parties controls or has the power to control both. 

I hereby declare that rights under contract or law have been conveyed to and remain with the small business concern iden- 
tified above with regard to the invention, entitled CHECK TRANSACTION PROCESSING 

METHOD AND SYSTEM by in ventor(s) 



David W. Deaton et al. 



described in 



{ X] the specification filed herewith 

I J application serial no. 

( j patent no. 



fifed 



issued 



If the rights held by the above identified small. business concern are not exclusive, each individual, concern or organization 
having rights to the invention is listed below* and no rights to the invention are held by any person, other than the inventor, 
who could not qualify as a small business concern under 37 CFR 1.9 (d) or by any concern which would not qualify as a 
small business concern under 37 CFR 1.9 (d) or a nonprofit organization under 37 CFR 1.9 (e). 
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TECHNICAL FIELD OF THE INVENTION 

This invention relates to transaction processing 



and analysis systems, including check verification 
systems, and more particularly, to a method and system for 
processing and developing a local customer database of 
customer information, such as check verification status 
and transaction frequency and dollar volume over specified 
intervals, that can be used for check verification, 
marketing and other customer relations purposes. 



BACKGROUND OF THE INVENTION 

Retail and other business establishments that 
serve a large number of customers generally have a problem 
obtaining transactional information about their customers, 
such as for identifying new customers and determining 
transactional patterns for repeat customers (such as 
transactional frequency and dollar volume). 

For those stores that experience a high volume 
of check transactions, an immediate customer information 
problem is determining whether to authorize a check 
transaction in the typical situation where the sales clerk 
does not personally know the purchaser. Beyond this 
immediate problem of check verification, these stores have 
a broader need for gathering transactional information 
that could be used in developing customer profiles useful 
in targeting advertising, marketing and promotions. 

For example, a typical grocery store does a high 
transactional volume with checks comprising a significant 
percentage of the total transactions (typically as much as 
85%) . These businesses strive for maximum efficiency in 
completing transactions at the checkout counter, which 
results in a minimum of contact between the customer and 
the sales clerk. In this sales environment, neither 
clerks nor store managers typically develop any 
significant personal relationship with an individual 
customer. 
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Since check transactions account for such a 
significant percentage of a grocery store's business, 
these stores naturally make an effort to minimize the 
number of bad checks that will be returned. Typically, 
the store will require an additional piece of 
identification, such as a driver's license and/or a major 
credit card. However, this requirement for additional 
identification reduces the efficiency of the checkout 
process, and inconveniences the significant majority of 
check transaction customers who do not write bad checks 
typically, a grocery store's bad check experience will be 
approximately 2% of its check transactions. 

Thus, check verification presents a store with 
problems in customer relations and risk management. A 
store naturally seeks to improve customer relations with 
the great majority of customers who do not present check 
transaction problems by efficiently and quickly 
authorizing check transactions. However, the store must 
guard against the financial risks from customers who do 
write bad checks, either as part of a concerted bad check 
scheme or as a result of less larcenous conduct that may 
range from simple bookkeeping mistakes to overly 
aggressive check floating. In the former case, bad check 
risk is greatly dependent upon abnormal check transaction 
activity over a given interval. In the latter cases, the 
bj.d check risk is greatly dependent upon check transaction 
history (total check transaction frequency and dollar 
volume at a store). 

The check transaction risk management problem 
has two principal aspects the risk that a person will 
write a bad check and the risk that a bad check cannot be 



recovered. Again, both of these risk factors are greatly 
dependent upon a customer's historical check transaction 
activity. As the total number of check transactions by a 
customer at a particular store increases, both the risk 
that the customer will write a bad check decreases, and 
more significantly, the risk that store will not be able 
to recover on a bad check decreases. 

For example, a customer with fewer than 200-300 
check transactions at a store presents a relatively high 
risk in terms of recovery on a bad check, while a customer 
with more than 600-700 check transactions presents a 
minimal risk. Thus, a store practicing risk management 
should put substantially more restrictions in terms of 
check transaction frequency and total dollar volume over 
given intervals in the former case than in the latter. 

These risk management problems are multiplied in 
the case of multiple store businesses, particularly in the 
case of concerted bad check cashing schemes. In that 
case, the typical pattern is to move from store to store 
within a relatively short period of time. 

Beyond these check verification and risk 
management problems, grocery stores have a broader problem 
in accumulating customer information because of the 
emphasis on minimizing the amount of time required for a 
sales transaction, and the attendant impersonality of the 
customer relationship. Thus, it is extremely difficult to 
develop any meaningful customer profiles, or to identify 
customer groups such as regular customers and new 
customers who might become regular customers. If a store 
could accumulate more detailed customer information, 
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customer profiles could be developed and used for targeted 
advertising, marketing and promotional programs. 

Accordingly, a need exists for a transaction 
processing system for individual stores (in both single 
and multiple store environments) that facilitates check 
transactions by improving the efficiency of the check 
verification process, and that maintains a local customer 
database containing transactional information about the 
store's customers useful for check verification risk 
management, and for other customer relations purposes such 
as identifying new customers and profiling regular 
customers . 

Check or credit verification systems are 
commonly used today to verify check/credit transactions. 
Typically, these systems include a negative-status 
database of individuals for whom check or credit 
transactions will not be authorized (for example, because 
of an outstanding bad check) . In response to requests for 
check transaction verification, these systems indicate 
that the customer's status is either positive (transaction 
anthorized) or negative (transaction not authorized). 

U.S. Patents RE. 30,579, RE. 30, 580, and RE. 30,821 
(Goldman) disclose a system for commercial retail 
establishments in which customer records are identified by 
arbitrary identification information such as a driver's 
license number and contain some customer status and 
transactional data (such as bad check history and 
frequency of checking transactions in a given period) . 
For each check transaction, the clerk enters into a 
transaction terminal the customer's arbitrary 
identification. Such systems have not been commercially 



practical, because store customers dislike having to 
identify themselves, particularly when they have been 
long-time customers of the store. 

In the systems disclosed by Goldman, if the 
customer database contains a corresponding customer 
record/ a customer status indication (positive or 
negative) is returned to the clerk. If the customer 
database does not contain a corresponding customer record, 
the system creates a new record, and indicates 
first- time/interim status for the customer. The database 
is regularly updated by changing customer status to 
reflect check transaction experience or the sufficient 
passage of time for check clearance to allow transfers 
from first-time/interim status to positive status. Such 
first-time/interim status as taught by Goldman is 
dangerous for the store owner, as a customer can gain 
access to a positive indication level, thus enabling the 
cashing of many checks in a short time period, by the 
clearing of only a single 'check. 

Existing check transaction processing systems 
are disadvantageous for high-volume check transaction 
operations. In particular, the Goldman patents do not 
disclose a practical system for businesses to efficiently 
verify check transactions, while developing a localized 
customer database for each store that may be used by the 
store to develop customer profiles useful for marketing 
and other customer relations purposes. The Goldman 
system, and others, are based on using some form of 
identification with the customer's check, a procedure that 
both slows the check transaction process and 
inconveniences the large majority of customers who will 



not present a bad check. Moreover, such systems as 
disclosed in the Goldman patent do not enable sufficient 
control over a customer's check transaction frequency and 
dollar volume, and thus subject the store owner to 
substantial financial risk. 

Many such systems require connecting a 
point-of-sale terminal through telephone lines to a remote 
transaction processing system, thereby increasing not only 
the cost of operating the systems, but also increasing the 
time for providing check verification. Also, existing 
systems typically do not focus on maintaining a local 
customer database useful not only for check transaction 
processing, but also for identifying new customers and 
developing customer profiles for regular customers. 
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SUMMARY OF THE INVENTION 

Important aspects of the present invention are 
to facilitate check transactions by reducing the 
requirements for customer identification, to enable a 
store to adopt a risk management approach to check 
verification based on a customer 1 s transactional history 
(frequency and dollar volume over specified intervals), 
and to improve a store's marketing and other customer 
relations programs by collecting transactional data for 
that store, both current and historical, that can be used 
to identify new customer's and develop customer profiles. 

More specifically, this invention is a check 
transaction processing system that uses a customer's 
checking account number as a unique customer 
identification number. Thus, the system does not require 
time-consuming checking of additional customer 
identification, but only requires the speedy entry of the 
customer's checking account number. The system operates 
at an individual store", and maintains at that store a 
local customer database of customer records, each 
identified by the corresponding customer check 
identification number. The customer records also include 
customer information, such as check verification data 
(such as verification status) as well as other selected 
transactional data (such as transaction frequency and 
dollar volume), the verification and transaction data 
being regularly updated with new data (such as during 
check transaction verification) . 

The system includes one or more transaction 
terminals, coupled to a transaction processor that stores 
the customer database. A transaction terminal is used to 
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transmit a customer information request (such as for check 
transaction verification), which includes a customer's 
check identification number, from the point-of-sale (POS) 
to the transaction processor. 

The transaction processor processes the customer 
information request, using the check identification number 
to search the customer database and retrieve the 
corresponding customer record, if any. Based on the 
customer information in the customer record, or the lack 
of a customer record, the transaction processor returns an 
appropriate response (such as check verification status) 
to the transaction terminal. 

Thus, the method of this invention for check 
transaction processing involves: (a) identifying a 
customer by the customer's unique check ID; (b) developing 
and maintaining for a store a local customer database of 
customer records, each identified by the corresponding 
customer check identification number, and each including 
customer information fsuch as verification status and 
transactional data); (c) generating a customer information 
request; (d) processing the request using the customer 
check identification number to access the corresponding 
customer record, if any; (e) returning an appropriate 
customer information response based on the customer 
information in the customer record; and (f) updating the 
customer database regularly to reflect new customer 
information. 

More specific aspects of the preferred 
embodiment of the invention are the following. 

The transaction terminals and the transaction 
processor form a token ring data communication network. 



Each transaction terminal includes (a) a keypad for 
entering check identification numbers, function codes and 
appropriate transaction data, which form customer 
information requests, and (b) a display for displaying the 
requests and the returned responses. 

The customer records in the customer database 
include an assigned check verification status, such as 
POSITIVE (transaction authorized), NEGATIVE (transaction 
not authorized) or CAUTION (transaction should be 
scrutinized or subject to certain conditions). The first 
time a customer attempts a check transaction at a store 
(i.e., a search of the customer database pursuant to a 
check verification request indicates no existing customer 
record), a new customer record with a CAUTION status is 
'created, and a CAUTION response is returned to the 
transaction terminal. The customer remains in the CAUTION 
status for a period of time sufficient for this initial 
check to clear or be returned. If this CAUTION/POSITIVE 
interval passes, the system automatically updates status 
to POSITIVE; if the check is returned, customer status is 
updated by inputting a NEGATIVE status. 

In addition to check* verification status data, 
the local customer database includes transactional data 
such as transaction frequency and dollar volume over 
specified intervals. This transactional data can be used 
to place conditions risk management on check transaction 
verification over and above verification status. For 
example, in the case of a customer with either CAUTION or 
POSITIVE status, if a check transaction exceeds certain 
specified transaction limits frequency and/or dollar 
amount over a specified interval (such as day, week or 
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total), a CALL MANAGER response is returned in response to 
a check verification request, regardless of customer 
status . 

Moreover, because the check transactional data 
is generated and maintained locally, it provides 
significant information about the store 1 s customers over 
and above the information necessary for check verification 
risk management. New customers are readily identified, 
and frequency and dollar volume information may be used to 
establish customer profiles and to target advertising, 
marketing and promotional programs, and for other customer 
relations purposes. 

In the case of a multiple store business, each 
store has a local check transaction processing system, 
with one of the systems being designated a host site and 
the rest being designated remote sites. At selected 
intervals, each remote system transmits, to the host 
selected customer information from its local customer 
database (such as customer records for those customers 
with CAUTION and NEGATIVE status including transactional 
data), which is used to update the host customer database 
to include this global customer information. The host, in 
turn, transmits that global customer information to the 
other remote systems. 

Check transaction processing is implemented by a 
multi-tasking program executing in the transaction 
processor. The program includes: (a) a terminal manager 
task that implements network data communication for the 
transaction terminals, communicating customer information 
requests and responses; (b) a Data Manager Task that 
controls the database operations necessary to respond to 
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customer information requests and to update the customer 
information in the database; and (c) an Event Manager Task 
that implements system activities such as backup and 
database purge, and in the case of multiple- store systems, 
implements host/remote communications activities to 
transfer selected customer information among the stores 
for updating each store's local customer database with the 
selected global customer information. 

Important features and advantages of this 
invention are the following. The check transaction 
processing system uses as a unique customer identification 
number the customer's check identification number, 
avoiding the requirement for additional identification and 
the attendant delay in completing the check transaction. 

The system develops and maintains a local 
customer database, allowing the store to accumulate 
customer information relevant to the store's customers 
over and above that information necessary for check 
verification. The system provides for the selection of 
procedures and criteria for database management and check 
verification, allowing the store owner/manager 
considerable flexibility in developing and using the 
customer information in the store's customer database. 

For check verification, the system uses three 
primary status levels POSITIVE, NEGATIVE and CAUTION 
allowing the store to identify those customers with a bad 
check outstanding, and to identify new customers and 
establish selected interim risk management procedures for 
granting those customers check transaction privileges. In 
addition to check verification status, the system collects 
and accumulates selected additional transactional data, 
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including frequency and dollar amounts over specified 
intervals (such as day/week/total) and other historical 
information, allowing the store to adopt risk management 
approach to check verification tailored to the store's 
particular customer and financial situation by 
conditioning check authorization on meeting certain 
selected transactional limits regardless of customer 
status (the CALL MANAGER response), and allowing the store 
to develop customer profiles and to target advertising, 
marketing and promotions, and otherwise improve customer 
relations . 

For multiple-store businesses, the system can 
use automatic host/remote transfer of selected customer 
information to upgrade the local customer database at each 
store with global customer information (such as those 
customers with CAUTION and NEGATIVE check verification 
status), thereby maximizing protection against bad checks 
while maintaining the local character of the store's 
customer database. ' 

The check transaction processing system is 
implemented by a multi-tasking program / and uses local 
area network data communication, among the transaction 
terminals and the transaction processor, allowing 
efficient operation of the system at each individual 
store. 

Other objects, features and advantages of this 
invention will be apparent from the drawings and • the 
following detailed description of the preferred 
embodiment, and the appended claims. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

FIGURE 1 shows the check transaction processing 
system of this invention, including a multiple store 
remote/host configuration. 

FIGURE 2A shows a transaction terminal, 
including the display and the keypad. 

FIGURE 2B shows schematic circuit detail for the 
transaction terminal. 

FIGURE* 3 functionally diagrams the check 
transaction processing system. 

FIGURE 4 diagrams the verification function. 

FIGURE 5 diagrams the local status update 
function for both Add and Delete NEGATIVE status. . 

FIGURES 6A and 6B diagram the global update 
function for, respectively, the host and a remote system. 

FIGURE 7 shows the program tasks that form the 
check transaction processing program. 

FIGURE 8 is a program flow diagram of the System 
Kernel that provides task switching and intertask 
communication for the other program tasks. 

FIGURE 9A is a program flow diagram of the Data 
Manager Task. 

FIGURES 9B-9H are program flow diagrams of 
selected function execution routines in the Data Manager 
Task, respectively, verify roll, add NEGATIVE, delete 
NEGATIVE, host global update (negative status records), 
host global update (customer records), and remote global 
update (customer records). 

FIGURES 10A and 10B are program flow diagrams 
of, respectively, the Terminal Manager Task network 
polling function, and the terminal request subtask. 
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FIGURES 11A and 11B are program flow diagrams 
of, respectively, the Event Manager Task, and the event 
subtask. 

FIGURE 12 is a program flow diagram of the Modem 
Manager Task. 
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DESCRIPTION OF THE PREFERRED EMBODIMENT 

The check transaction processing system of the 
present invention enables a store with a significant 
volume of check transactions to accumulate and process 
transactional customer information for two main purposes: 
check verification and customer profiles. The system 
operates at the store using a local database of customer 
information useful in that store's business. 

A customer's bank checking account number 
provides a unique identification for that customer 
using this check ID, a customer record is created and 
included in the local customer database. The customer 
record includes an assigned customer verification status, 
as well as selected transactional data. Customer status 
designations include POSITIVE, NEGATIVE and CAUTION, while 
transactional data ■ includes transaction frequency and 
dollar volume over given intervals (such as Day/Week/Total 
or DWT). Selected transactional (CALL MANAGER) limits are 
assigned to both CAUTION and POSITIVE status. This 
customer information (customer status and transactional 
data) in the customer database is continuously updated 

(a) on a local basis through either processing check 
verification requests, or inputting customer status, and 

(b) in the case of a multiple store business, on a global 
basis through inter-store transfers of selected customer 
information (such as CAUTION and NEGATIVE status 
information) . 

The description of the preferred embodiment of 
the check transaction processing system is organized as 
follows : 
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0 Hardware Description 



1.1. System Overview 

1.2. Data Communications Network 

1.3. Transaction Terminal 

1.4. Multiple-Store Configuration 

1.5. Exemplary Components 

0 Functional Description 

2.1. Database Structure 

2.2. Function Codes 

2.3. Verify/Query 

2.4. Local StatusUpdate 

2.5. Global .Update 

2.6. Purge 

2.7. Event/Activity 

2.8. Communications 

2.9. System 

2.10. Risk Management 

2.11. Customer Profiles 

0 Program Description 

3.1. General 

3.2. System Kernel 

3.3. Data Manager Task 

3.4. Terminal Manager Task 

3.5. Event Manager Task 

3.6. Modem Manager Task 

3.7. System/Screen Tasks 
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4.0 Additional Embodiments 

4.1. Hardware 

4.2. Standard Multi-Tasking Operating System 

1.0 Check Transaction Processing System 

The check transaction processing system is 
located at a store, and maintains a local customer 
database for that store. For a multiple store business, a 
local system is located at each store and global customer 
information transfers are used to supplement the 
essentially local customer database. 

1.1. System Overview . As shown in FIGURE 1, a 
check transaction processing system 110 located at a store 
includes a transaction processor 112 coupled to a disk 
system 114 that stores the customer database used in check 
transaction processing. Transaction processor 112 handles 
all file I/O for accessing, managing and updating the 
customer database. ' 

Transaction processor 112 is coupled through a 
network data communications interface 116 (including 
network communications ports and associated drivers) and a 
network bus 118 to a plurality of transaction terminals 
120. . Transaction processor 112 is able to communicate 
with other check transaction processing systems through a 
telecommunications interface 117 (including a modem). 

Transaction terminals 120 are each located at a 
point-of-sale (such as a* grocefy store checkout stand). 
Transaction terminals 120 are used to communicate 
information to transaction processor 112 for check 
transaction processing and customer database management. 



A transaction terminal transmits a request (including a 
function code identifying the requested function together 
with other request data) to the transaction processor, 
which processes the request and returns an appropriate 
response. 

For example, in the case of check verification, 
a transaction terminal is used to transmit a verification 
request -- the customer's check ID, the verification 
function code, and the dollar amount. The transaction 
processor processes the request, updates the customer 
database to reflect that transaction, and returns a 
customer verification status response. 

1.2. Data Communications Network . Data communi- 
cations between transaction processor 112 and transaction 
terminals 120 is implemented using a multi-drop token ring 
network. Network bus 118 connects the transaction 
terminals to the transaction processor in a star 
configuration so that 311 data signals transmitted over 
the network are received at each node. Each transaction 
terminal 120 is assigned a unique terminal address to 
identify its data communications. 

Transaction processor 112 implements a 

token-passing protocol by broadcasting polling sequences 

(or cycles) in which tokens are sequentially addressed to 

the transaction terminals. For each poll, the transaction 

processor sends to a terminal one of two tokens (which 

both include the terminal address): 

POLL Token An invitation for the terminal 

to transmit data 

RXDATA Token Includes data requested by the 

terminal 
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In response to a POLL token, the transaction terminal 
transmits back one of two answers:' 

TXDATA Answer Includes data entered into the 
terminal 

NODATA Answer Indicates no data 

During any given polling sequence, each 
transaction terminal is in one of three polling states 
that control the polling operation: 

Poll Send a POLL token 

Wait Do not send a token until 

requested data is available 

Data Send an RXDATA token that 

includes the requested data in 
the terminal's buffer 

For example, in response to a POLL token, a 
transaction terminal may transmit a TXDATA Answer 
containing a check verification request. Once the request 
is transmitted, the terminal is placed in the Wait state 
until the verification response from the transaction 
processor is available. . The response is placed in the 
terminal's buffer, and the terminal is placed in the Data 
state. The response is included in an RXDATA token sent 
to the terminal during the next polling sequence, and the 
terminal is placed in the Poll state ready to receive a 
POLL token in the next polling sequence. 

For the preferred embodiment, network 
communications interface 116 provides 32 ports for up to 
32 transaction terminals. The data communications network 
uses the RS485 line protocol, which specifies differential 
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signal lines SIG+ and SIG-, as well as +12V and ground 
lines. . The network communications interface and the 
corresponding interfaces for each transaction terminal use 
a differential line driver for signal communication over 
network bus 118, which provides the necessary 4-wire 
signal path. 

1.3. Transaction Terminal . As shown in FIGURE 
2A, each transaction terminal 120 includes a keypad 122 
and a display 124. Keypad 122 is a 4X4 key matrix that 
includes specific keys for Function, Enter, Scroll, Clear 
and Back Space, as well as 0-9 and $. Display 124 is a 
liquid crystal display capable of displaying two lines of 
up to twenty characters each. 

For example, to initiate a check verification 
request, keypad 122 is used to enter the customer's check 
ID and the amount "of the check, along with the function 
code designating check verification. This request is 
displayed on display 124, and sent to transaction 
processor 112. The check verification response, including 
the customer's verification status (such as POSITIVE, 
NEGATIVE or CAUTION), returned by the transaction 
processor is then displayed on display 124. 

As shown in FIGURE 2B, a transaction terminal 
120 includes: 

(a) A Z8 microprocessor 130; 

(b) An associated address latch 132; 

(c) An EPROM 134; 

(d) An LCD (liquid crystal display) module 136; 
and 
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(e) A differential transceiver 138. 
Address and data paths are provided by an Address/Data Bus 
and a separate Address Bus. 

The transaction terminal is coupled to the RS485 
multi-drop network bus (118 in FIGURE 1) through a 5-Pin 
DIN connector 140. The RS485 network bus provides signal 
lines SIG+ and SIG-, along with a +12 volt power line and 
a ground line. 

EPROM 134 provides program memory for 
microprocessor 130, while LCD module 136 constitutes data 
memory. That is, the LCD module functionally interfaces 
to the microprocessor as memory, providing an 80-character 
display data register that is treated by the 
microprocessor as data memory. 

EPROM 134 stores programs to control keypad 122, 
display 124 (i.e., LCD module 136) and network data 
communications. The keypad program includes conventional 
routines for decoding key-struck signals and receiving 
entered characters, as 'well as key-debouncing and N-key 
rollover. The display program includes conventional 
routines that write characters to and read characters from 
the display data register in LCD module 136. To that end, 
the display program provides mode control commands to LCD 
module 136 that control read/write operations, as well as 
operations for cursor positioning, backspace and scroll. 
The network program controls token-ring network 
communications, including establishing a terminal polling 
address when the transaction terminal becomes active, 
detecting POLL tokens addressed to the transaction 
terminal, building and sending NODATA and TXDATA answers, 
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and receiving RXDATA tokens containing response data for 
the transaction. 

LCD module 136 is a self-contained liquid 
crystal display module that includes liquid crystal 
display 124, and provides many display control functions 
internally. Display 124 is arranged in two lines of 20 
characters each, with the internal 80-character display 
data register providing 40 characters of display memory 
for each line. Each line is independently scrolled under 
control of the LCD module in response to microprocessor 
mode control commands (for example, when the scroll key on 
keypad 122- is depressed). In addition to the internal 
display data register, the LCD module includes an internal 
control/status register. Logically, these registers are 
treated as, respectively, data and control/status ports. 
Data may be read to or written from the data port, while 
control is written to and status is read from the 
control/status j^^port . 

From above, the display control program in EPROM 
134 provides the various mode control commands that invoke 
the display control functions implemented by the LCD 
module. For example, in response to appropriate mode 
control commands, the LCD module performs the necessary 
internal operations to move the cursor, output the 
character under the cursor, write a character in the 
cursor position, delete a character in the cursor 
position, clear the display, and output sequentially all 
characters in the display data register (such as after the 
enter key is depressed). 

Microprocessor 130 provides four input/output 
ports 0-3. Port 0 is output only, and provides the higher 



order address bits A08-A12 over the Address Bus (the 3 
higher order bits A13-A15 of the 16-bit 28 microprocessor 
address are not used by the transaction terminal) . Port 1 
is input/output, providing the lower order address bits 
A00-A07 and receiving 8-bit data bytes over the 
Address/Data Bus. Port 2 is input only, and is coupled to 
the column/row matrix lines of the 4X4 keypad matrix for 
keypad 122, i.e., column lines C0-C3 and row lines R0-R3 . 

Port 3 (0-7) is a multi-purpose input/output 
port. Pins 0 and 7 are a serial I/O port for an internal 
UART (universal asynchronous receiver transmitter) . Pin 5 
is an output drive enable line that controls the 
transmit/receive state of differential line driver 138. 
Pin 4 is a data memory DM line used to select either 
program memory (i.e., EPROM 134) or data memory (i.e., LCD 
module 136). Pins 1-3 are an I/O port for a credit card 
reader (not used in the preferred embodiment), and Pin 6 
is an output port for a buzzer. 

In addition ' to the four I/O ports, 
microprocessor 130 provides an address strobe line AS, a 
data strobe line DS and read/write line R/W. 

A clock circuit 131 includes a crystal 
oscillator that establishes a 7.3728 MHz system clock. 
The 28 microprocessor is clocked down (from its 12 MHz 
specification) to accommodate the LCD module's response 
time. 

Address latch 132 receives the lower order 
address bits AOO-A07 from microprocessor port 1 over the 
Address/Data Bus during the first address cycle. The 
address latch is enabled to latch these address bits by a 
microprocessor address strobe provided through an inverter 
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142. The latched address bits A00-A07 are available at 
the output of address latch 132 which is coupled to the 
Address Bus . 

EPROM 134 receives a 12-bit address AO0-A12 from 
the Address Bus. The lower order bits A00-AO7 are 
provided by address latch 132, and are available on the 
Address Bus during the second address cycle when the 
higher order bits A8-A12 are provided by microprocessor 
port 0 over the Address Bus. Thus, EPROM 134 receives the 
complete 12-bit address A00-A12 from the Address Bus 
during the second address cycle. The addressed data byte 
AD0-AD7 is available from the EPROM output port over the 
Address/Data Bus and may be read when microprocessor 130 
provides a data strobe DS to the chip enable CE input to 
the EPROM. 

LCD module 136 includes an I/O port (pins D0-D7) 
coupled to the Address/Data Bus (lines AD0-AD7). To 
connect either the display data register or the 
control/status register 'to the I/O port, Microprocessor 
130 selects either data port operation or control/status 
port operation with a register select signal provided by 
the address bit A00 from the Address Bus to the R/S input 
of the LCD module — if A00 is even (logic 0), the display 
data register is connected to the I/O port, and if A00 is 
odd (logic 1), the control/status register is connected. 
Read/write operation is selected by R/W signal from 
microprocessor 130 to the R/W input to LCD module 136. 

LCD module 136 is enabled for output over the 
Address/Data Bus by an enable signal from a NOR gate 146, 
which receives input from the microprocessor's data strobe 
DS line and data memory DM line (port 3, pin 4). That is, 
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LCD module 136 may be read only if both the data strobe 
and data memory lines are active. In contrast, EPROM 134 
is enabled for a read operation only if the data strobe 
line is active while the data memory line is inactive 
causing an active output from an inverter 144. In this 
manner, microprocessor 130 uses the data memory line to 
select between program memory (EPROM 134) and data memory 
(LCD module 136) . 

A potentiometer 148 is used to adjust contrast 
for the LCD display 124. The potentiometer is connected 
between the pins +5 volts and ground on LCD module 136, 
with the potentiometer voltage being applied to the 
voltage reference pin VREF. 

To read instructions from EPROM 134, 
microprocessor 130 provides a 12-bit address on the 
Address Bus -- the lower order address bits A0O-A07 from 
port 1 through address latch 132, and the higher order 
address bits A08-A12 from port 0. EPROM 134 is enabled 
for output by the data memory line (port 3, pin 4) being 
held inactive resulting in an active output-enable signal 
from inverter 144 to the EPROM. Conversely, LCD module 
136 is disabled for a read operation because the inactive 
data memory line insures an inactive signal from NOR gate 
146 to the LCD module, thereby insuring that EPROM 134- has 
exclusive access to the Address/Data Bus. During the read 
cycle, microprocessor 130 enables EPROM 134 to output the 
addressed data byte by providing a data strobe DS to the 
chip-enable input to the EPROM. 

To read display data from the display data 
register in LCD module 136, Microprocessor 130 executes a 
read display routine in the display control program stored 
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in EPROM 134. Microprocessor 130 first disenables EPROM 
13.4 by holding the data memory line (port 3, pin 4) 
active, causing the output-enable output from inverter 146 
to be inactive. LCD module 136 is then enabled for 
input/output when a microprocessor data strobe drives 
active the output from NOR gate 148, which now has both 
its inputs (DM and DS) active. 

Once LCD module 136 has been given access to the 
Address/Data Bus, a display-data-register read operation 
is accomplished as follows. Microprocessor 130 outputs 
from port 1 an LCD mode control byte including a register 
select bit A00 over the Address/Data Bus. The register 
select bit is coupled through address latch 132 and the 
Address Bus to the RS input to LCD module 136 which 
selects bit is in the C/S state, causing LCD module 136 to 
select the control/status register for I/O access to the 
Address/Data Bus.' Microprocessor 130 also places its 
read/write R/W line in the write state, so that the mode 
control byte can be written into the control/status 
register. Microprocessor 130 then provides a data strobe 
DS that enables LCD module 136 to latch the mode control 
byte from the Address/Data Bus into the control/status 
register. 

In accordance with this mode control command, 
LCD module 136 places a not-ready status byte in the 
control status register, makes the designated display 
character in the display data register available for 
output on the Address/Data Bus, and then places a ready 
status byte into the control/status register. 
Microprocessor 130 switches the read/write line to read 
(the control/status register is still selected for I/O), 
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and then provides a data strobe DS to read the status byte 
in the control/status register. (The microprocessor 
continually strokes the LCD Module until a ready status 
byte is returned from the control/status register. ) 

Microprocessor 130 then outputs a register 
select bit (AOO) that causes LCD module 136 to select the 
display data register for output. Finally, the 
microprocessor provides a data strobe to read the first 
display data character over the Address/Data Bus into port 
1. 

This procedure --select control/status, read 
status, select display data, read display data-- is 
continued until all requested display data characters have 
been read. That is, microprocessor 130 first reads the 
status register to determine when LCD module 136 is ready 
(i.e., when the next display data character is available), 
and then reads the character. 

The procedure by which microprocessor 130 
provides display data characters for display by LCD module 
136, writing the characters into the display data 
register, is analogous to the procedure for reading 
display data characters. Executing a write display 
routine in the display control program, microprocessor 136 
first writes a corresponding mode control command into the 
control/status register of the LCD module, and then reads 
status to determine when the LCD module is ready. 
Microprocessor 130 then selects the display data register, 
and writes the first display data character over the 
Address/Data Bus. Microprocessor 130 reads the status 
register to confirm that the LCD module is ready prior to 
writing the next display data character. This procedure 
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of reading the status register and then writing a display 
data character is continued until all display data 
characters have been written. 

Differential transceiver 138 controls data 
communications over the network bus 118 connected to 
connector 140. The RS485 communications protocol is 
implemented by microprocessor 130 executing the network 
communications program stored in EPROM 134. Port 3 of 
microprocessor 130 is used as a communications port, with 
pins 0 and 7 providing a serial I/O port, and pin 5 
providing a transceiver drive enable line through an 
inverter 152 (the differential transceiver is in the 
transmit mode if the signal is active, and in the receive 
mode if the signal is inactive). 

On the network side of differential transceiver 
138, signal lines 6 and 7 are coupled, respectively, to 
the network bus signal lines SIG+ and SIG-. These signal 
lines are coupled to the +12 volt line through opposite 
sides of a protective diode network 154. 

While waiting for a token (either POLL or 
RXDATA) over the network bus, microprocessor 130 holds the 
transceiver drive enable line inactive, thereby placing 
differential transceiver 138 in the receive mode. When a 
'token is received through differential transceiver 138 
into the serial I/O port (port 3, pins 0 and 7), 
microprocessor 138 switches the transceiver drive enable 
line active and transmits either a TXDATA or NODATA answer 
via the serial I/O port and the differential transceiver. 

Keypad input is accomplished in a conventional 
manner using a 4 X 4 keypad matrix with column lines C0-C3 
and row lines R0-R3 . Key-struck decoding is accomplished 
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as follows. Column lines C0-C3 are normally held high by 
a resistor network 160, while microprocessor 130 (port 2) 
holds the row lines R0-R3 low. When a key is struck, the 
corresponding column line is brought into contact with 
that key's row line, and the column line is brought low, 
which is detected by microprocessor 130. The 
microprocessor then switches the port 2 lines high, and 
sequentially drops a row. line low until the key-struck 
column line goes low, thereby identifying the key that was 
struck by its row/column intersection. 

Keypad control functions, such as debouncing and 
N-key rollover are accomplished in a conventional manner 
using program routines of the keypad control program 
stored in EPROM 134. 

Power for the transaction terminal is provided 
by a voltage regulator 165 that receives +12 volts from 
the +12 volt line of the network bus. Voltage . regulator 
165 provides a stable +5 volt logic level. 

A transaction 7 " terminal is initialized as 
follows. At power on, voltage regulator 165 provides a 
reset signal to microprocessor 130 when the +5 volt logic 
level is stable. Microprocessor 130 turns port 0 off, so 
that the Address Bus is controlled by the low-current 
resistor network 160, which holds the Address Bus lines 
A08-A12 high. 

Microprocessor 130 outputs from port 1 an 
initialization address over the Address/Data Bus, which is 
latched into address latch 132 and placed on the Address 
Bus. EPROM 134 receives the initialization address 
A00-A12 (with bits A08-A12 being held high by resistor 
network 160) , and makes the addressed instruction 
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available at its data output port. Microprocessor 130 then 
reads the first instruction over the Address/Data Bus. 
Port 0 is turned on, so that resistor network 160 no 
longer controls the address lines A08-A12 of the Address 
Bus, and normal operation commences under control of 
microprocessor 130. 

1.4. Multiple-Store Configuration . As shown in 
FIGURE 1, for businesses with multiple stores, a check 
transaction processing system 110 is located in each 
store . 

One store is designated as a "host" system, and 
the other stores are designated as "remote" systems. The 
host system coordinates the global exchange of check 
verification data and other customer information, but 
otherwise operates as a -local system for that store in the 
same manner as the remote systems. Operation as a host 
does not affect concurrent local operation, i.e., 
host/remote status is transparent to the check transaction 
processing operation at each store. 

Each store operates relatively autonomously in 
developing and maintaining its local customer database and 
providing check transaction processing. However, the 
stores are also able to globally exchange certain customer 
information useful to all of the stores, particularly for 
purposes of check verification. For example, while it is 
probably unnecessary for the stores to exchange 
information about customers who typically frequent only a 
single store and do not present check transaction 
problems, the stores will probably want to exchange 
information about customers who have written bad checks at 
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one or more stores, or who are in a cautionary status as 
new customers. Such a global exchange of customer 
information reduces the likelihood that the business will 
experience a significant loss from a concerted bad check 
writer . 

Each store's customer database is updated with 
both local and global customer information. Each local 
check transaction processing system 110, including the 
designated host system, continually updates its customer 
database with local customer information, either 
automatically through processing check transactions or 
through operator-input of customer status data (such as 
negative status information). At regular intervals, each 
remote system transfers to the host selected customer 
information (such as negative and caution status 
information) . The host updates its customer database with 
this customer information, and transfers back to each 
remote system global customer information from all remote 
systems. Each remote srystem then updates its customer 
database with this global customer information. 

1.5. Exemplary Components . The detailed 

specifications for transaction processor 112, and its 
associated disk storage 114, and network communications 
interface 116 are not critical to this invention, being a 
matter of design choice. For the preferred embodiment, 
transaction processor 112 uses a Western Digital Processor 
Board Model No. WD286-WDM2 based on the Intel 80286 
processor chip. Disk storage unit 114 is a Seagate 
Technologies Model ST225, and communications interface 116 
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is Sealevel Systems RS485 Communications Board Model 
No'. SIO-485. The transaction processor runs MSDOS 3.3. 

The detailed specification for point-of-sale 
transaction terminals 120 is not critical to this 
invention, being a matter of routine design specification. 
For the preferred embodiment, transaction terminal 120 
includes the following components: 

Microprocessor 130 Zilog 28 (86C9112PSC) 

Address Latch 132 74HC373 

EPROM 134 27C64 

LCD Module 136 Optrex DMC16207 

4X4 Keypad Standard 4X4 matrix 

Diff. Transceiver 75176 (R5485 compatible) 

Voltage Regulator LM2925 

Alternative similar point-of-sale units are 
commercially available, such as from Omron Business 
Systems Model No. C.A.T.' 90. 

2.0 Functional Description 

As diagrammed in FIGURE 3a, the check 
transaction processing system performs the following 
general functions: 

(a) Verification (with Transactional Update) 
and Query 

(b) Local Status Update 

(c) Global Update 

(d) Event-driven activities 
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(e) Customer database purge 

(f) Host/Remote communications 

as well as the customer database management operations 
necessary to support these functions. In addition, 
certain system information and diagnostic functions are 
performed . 

The verification- function involves sending a 
request for check transaction verification from a 
point-of-sale transaction terminal to the transaction 
processor, which performs the necessary database 
operations to process the request, update the customer 
database with transactional data (such as frequency and 
dollar amount) to reflect the current transaction, and 
return an appropriate response. The local status update 
function involves continuously inputting customer status 
changes (particularly to reflect bad check experience) for 
customers in a store's local customer database. The 
global update function, for multiple- store systems, 
involves continuously transferring among the stores 
selected customer information (preferably caution and 
negative status information) . The purge function involves 
removing obsolete or unwanted customer records from the 
customer database based on specified purging criteria. The 
event-driven activities involve certain database 
management functions (such as purge and backup), as well 
as host/remote communications for global update, 
automatically performed at regular intervals. 



2.1. Database Structure . The customer database 
includes all customer information used and maintained by 
the check transaction processing system. The customer 
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database comprises two separate files containing customer 
information: the customer file and the negative status 
file. In addition, a system control file contains 
transactional limits used during check verification and 
purge limits . 

The customer file contains customer records that 
include the .following customer information: 



Field 



Description 



Check ID 



Customer checking account number 



Verification Status 



POSITIVE, NEGATIVE, CAUTION, CASH 
ONLY, or STOLEN 



User Flags 



User assigned flags that designate 
a customer as PRE APPROVED for check 
transactions regardless of any 
transactional limits, or as being 
authorized for check transactions 
on a MANAGER ONLY approval basis 
regardless of actual status 



Transfer Date/Time 



Date/time the customer record was 
last accessed and updated (written 
to disk), used in host/remote 
transfers for global update 
(transfers from host to remote 
generally do not affect this date) 
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Access Date/Time 



Last date/time the customer record 
was accessed and updated (a query- 
function does not change the access 
date/time ) 



Status Change Date 



Date/time customer status changed . 
(e.g., CAUTION to POSITIVE) 



DWT Frequency 



Day/Week/Total values for 
transaction frequency (updated 
transactionally during check 
verification and globally) 



DWT $Amount 



Day/Week/Total dollar amounts 
(updated transactionally during 
check verification and globally) 



Previous Status . 



Customer 1 s previous status (such as 
CAUTION prior to being rolled 
POSITIVE) 



Frequency Since 
Transfer 



Total number of check transactions 
since the last global transfer 



$Amount Since Total dollar volume since the last 
Transfer global transfer 

The file specification for a customer record is 
set forth in Table 1 at the end of the specification. 

The customer file is indexed by (a) check ID, 
and (b) status/transfer date/check ID. 




37 



The preferred intervals for maintaining 
frequency and dollar amount transactional data are 
Day/Week/Total, where the day is the current 24-hour 
period, the week is the previous 7 days, and the total is 
the total since the customer's first check transaction. 
The DWT designation will be used throughout this 
specification to indicate the three separate values for 
either Frequency or $Amount. Preferably, DWT Frequency 
and $Amounts are maintained on a global basis, so that for 
those records that have been globally updated (such as 
NEGATIVE and CAUTION status customer records), the DWT 
values will be global rather than local. Alternatively, 
separate local and global DWT transactional data can be 
maintained in the customer records, as shown in Table 2. 

A customer can be assigned one of five check 
verification status designations: 



Status ~ Description 

CAUTION The customer is a new customer, and a 

specified check clearance interval since 
the customer's first check transaction has 
not passed 



NEGATIVE 



The customer has one or more outstanding 
bad checks at any store location 
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POSITIVE The specified check clearance interval 

since the customer's first check 
transaction has passed, and no bad checks 
are outstanding at any store location 

CASH ONLY The customer is not authorized to cash 

checks, even though no bad checks are 
, outstanding 

STOLEN ; The customer has reported stolen checks 

Customer status is assigned during customer 
record creation, and then updated ( transactionally, 
locally or globally) to reflect changes in customer 
status, such as due to elapsed time between check 
transactions or bad check history. 

In addition, the local update function can be 
used to assign to a customer either of the following user 
flag designations, which override normal status responses 
to check verification or status query requests: 



User Flag Description 

PRE APPROVED The customer has been pre-approved for 
check transactions that may otherwise 
exceed certain transactional limits applied 
even to customers with POSITIVE status 
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MANAGER ONLY The customer is ^ not authorized to cash 
checks without manager approval, even 
though no bad checks are outstanding 

In response to a check verification (or 
status query) request entered .at a transaction terminal, 
the transaction processor returns a response with either 
customer status, or if specified transactional limits have 
been exceeded, a CALL MANAGER directive, unless the 
PREAPPROVED or MANAGER ONLY user flags in the customers 
record have been set. Generally, a check transaction will 
be authorized if the customer has a POSITIVE status or is 
PREAPPROVED , will require manager approval for MANAGER 
ONLY regardless of status, and will be refused if customer 
status is NEGATIVE, CASH ONLY or STOLEN. Check 
authorization for customers with CAUTION status is a 
matter of store policy. For example, check authorization 
can depend upon DWT Frequency or $Amount, or the type of 
check transaction (such as amount of purchase only), or 
upon having the check transaction approved by a store 
manager. 

The CALL MANAGER directive is not a 
verification status contained in a customer record, but 
rather, is the response to a verification^ request if, for 
any status"" -"(including POSITIVE), the current check 
transaction causes transactional limits specified in the 
system control file for DWT Frequency and $Amount to be 
exceeded. 
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The negative status file contains negative 
status records that include the following customer 
information (by location for multiple store systems): 



Field 



Description 



Check ID 
Location 



Customer checking account number 

The location identification for the 
store (each store having a NEGATIVE 
and/or CASH ONLY status history is 
assigned a separate negative status 
record) 



NEGATIVE Status 



Active That location has a bad 
check outstanding 
Inactive That location has no 
bad checks outstanding 



CASH ONLY Status 



Access Date/Time 



Active That location has 
designated the customer as CASH 
ONLY 

Inactive — That location has not 
designated the customer CASH ONLY 

Last date/time the negative status 
record was accessed and updated (a 
query function does not change this 
date) 
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NEGATIVE Date/Time Date/time the status first became 

NEGATIVE 

CASH ONLY Date/Time Date/time the status first became 

CASH ONLY 

BAD Frequency Total number of bad checks at that 

location 

BAD $Amount Total dollar amount in bad checks 
at that location 

The file specification for a negative status 
record is set forth in Table 2 at the end of the 
specification. 

The negative status file is indexed by 
(a) status/check ^ID/location, and (b) status/access 
date/check ID/location. 

The negative ' status file supplements the 
customer file for those customers with a bad check history 
by recording BAD Frequency/$Amount by location, and also 
maintains CASH ONLY status by location. 

The system control file includes the following 
selectable limits: 
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Limits 



Description 



CAUTION/POSITIVE 



This limit defines a check 
clearance interval for new 
customers who will be rolled for 
check transactions after that 
interval (assuming the first check 
is not returned) 



CALL MANAGER 



Separate DWT limits are provided by 
status for both Frequency and 
$Amount / defining the transactional 
limits applied to each status 



PURGE 



Separate Purge limits are specified 
for each of the five customer 
status designations; also used to 
define a Reset/CAUTION interval 



The file specification for the system control 
file is contained in Table 3 at the end of the 
specification. 

These limits are all specified by the user 
during system configuration. The CALL MANAGER .limits are 
used to override the normal customer status response to a 
verification request when any DWT Frequency/$Amount CALL 
MANAGER limit is exceeded by the current check 
transaction. As an alternative to using the Purge limits 
[ for deleting customer records with a specified (by status) 
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degree of obsolescence, these limits can be used to roll a 
POSITIVE or any other status back to CAUTION if the 
specified Reset/CAUTION interval between check 
transactions (defined by the corresponding Purge limit) 
has passed. In addition to these limits, the system 
control file contains various system information. 

The specific design of the customer database, 
and in particular the file specifications for the customer 
file, negative status file, and system control file, are 
not critical to the invention, being a matter of design 
choice. Any customer database will likely comprise 
customer records identified by the customer check ID, and 
include selected transactional/customer information; such 
as check verification status and transactional frequency 
and dollar volume over specified intervals. 

2.2. Function Codes . The specific functions 
available in the check transaction processing system are 
invoked by entering at a transaction terminal a request 
including an appropriate function code (function key plus 
code number) and request data (such as check ID and 
$ Amount) . 

The specific check transaction processing 
functions are set forth in Table 4 at the end of the 
specification, with each function being described in terms 
of function code, description, keypad input, and keypad 
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output. These functions are in the following general 
categories: 



Function 



Description (Function Code) 



Verify 



Request check verification status 
for the current check transaction 
(F55) (updating the corresponding 
customer record to reflect the 
current transaction) 



Query 



Request information about status 
(Fl), NEGATIVE status and locations 
(F2, F3, F4) and DWT Frequency and 
$Amounts (F5) (the customer 
database is not updated) 



Input Status 



Add (F40, F41, F44) and Delete 
(F60, F61, F62, F63 , and F66) the 
status values CASH ONLY, STOLEN and 
NEGATIVE, and Add (F42, F43 ) and 
Delete (F62, F63 ) PRE-APPROVED and 
MANAGER ONLY user flags 



Event Activity 



Start (F950) and Stop (F951) an 
event activity, request event time 
(F952), and request activity status 
(F953) 
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System Information Request certain system information, 

including memory usage ( F902 ) , disk 
usage (F903), customer file size 
(F904), negative status file size 
(F905), C AUT I ON /POSITIVE roll 
period (F906, F907), Purge limits 
(F906, F908-F912) CALL MANAGER 
limits (F906, F913-F917) 

System Diagnostics Request system diagnostic 

functions, including log-in/out 
(F77/F88), keypad debug (F960), 
modem debug (F970), data manager 
debug (F980), open/close customer 
database (F981/F982) and shutdown 

(F999) 

2.3. Verify/Query . The verify function is used 
both to provide verification status (such as POSITIVE, 
NEGATIVE or CAUTION) for a check transaction, and to 
update the transactional data in the customer database. 
The principal difference between the verify and query 
functions is that, while both functions retrieve the 
specified (by check ID) customer record (or in the case of 
query, the negative status record) to provide an 
appropriate response, only the verify function actually 
updates the customer database by writing the updated 
customer record back to disk. 

FIGURE 4 diagrams the check verification 
function. A check verification function is initiated 
(202) by entering a verify request (check ID/ function 
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code/$Amount ) from a transaction terminal, which is 
transmitted to the transaction processor for check 
transaction processing and to determine the appropriate 
check verification response. 

The transaction processor uses the check ID to 
search (204) the customer file for a corresponding 
customer record, which is retrieved (206), or if it 
doesn't exist, created (208) with a CAUTION status. The 
customer record is updated (210) by rolling Access 
Date/Time, Status and DWT Frequency and $Amount to reflect 
the current access date/time. 

First, the Access Date/Time in the customer 
record is rolled (212) forward to the date/time for the 
current check transaction, establishing the transaction 
interval, i.e. the time elapsed since the customer's last 
check transaction. 

Next, for"" a given status, the transaction 
interval is compared (214) with a corresponding selected 
reset/CAUTION interval -- -if the transaction interval is 
such that the reset/CAUTION interval for the customer's 
status is exceeded, Status is rolled (215) to CAUTION, and 
the customer is treated as a new customer from that time. 
If the customer record has a CAUTION status, the 
transaction interval is compared (216) with a selected 
C AUT I ON /POSITIVE limit defining a check clearance period 
— if this check clearance period has passed, the CAUTION 
status is rolled (217) POSITIVE. 

The last roll/update operation is to roll (218) 
the DWT values for Frequency and $Amount to reflect the 
current access date/time. 
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After the roll/update operation (210) updates 
the customer record to reflect the current access 
date/time, the current transactional data are added (220) 
by incrementing DWT Frequency and adding the transaction 
$Amount to the corresponding DWT $Amount. The DWT 
transactional data in the updated customer record, now 
reflects the current transaction. 

Next,, the user flags in the customer record are 
checked (222) if the MANAGER ONLY flag is set, a 

MANAGER ONLY response is returned (225) regardless of 
status, while if the PREAPPROVED flag is set, the normal 
status response (POSITIVE) is returned (226) regardless of 
any transactional CALL MANAGER limits. 

Finally, DWT Frequency/$Amount are compared 
(228) with the CALL MANAGER limits for the customer's 
status to determine whether any of these limits are 
exceeded. If not, a normal response with the customer's 
check verification status is returned (226); if any limit 
is exceeded, a CALL MANAGER response is returned (229). 

For the status query function, the same 
roll/update operation (210) is performed to provide a 
customer record with updated Access Date/Time, Status and 
DWT Frequency/$Amount from which an appropriate status 
response can be derived. However, the updated customer 
record is only used to derive the response to the query 
request -- the updated record is not written back to disk, 
so the customer database is not updated. 



2.4. Local Status Update . Local status update 
of the customer database is accomplished by inputting 
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certain status (and user flag) information to reflect bad 
check experience or store policy. 

Status input functions are used to Add or Delete 
the status values NEGATIVE, CASH ONLY and STOLEN. 
Typically these functions will involve modifying the 
Status of an existing customer record and/or negative 
status record, although new records may be created. In 
addition, local input functions are used to Add or Delete 
user flags that designate the customer as PREAPPROVED or 
MANAGER ONLY . 

For multiple store systems, a separate negative 
status record is kept for each location having a NEGATIVE 
and/or CASH ONLY status history. Thus, assuming negative 
status records are transferred during the global update 
function, each store's negative status file will contain 
separate negative status records for the various 
locations, sometimes for the same customer. Generally, a 
store can only affect through the local update function, 
negative status records for its location. 

For each status input function / the update 
operation for the customer record includes the roll/update 
operation described in connection with FIGURE 4 (210) to 
reflect the current access (update) to the customer record 
(which is written to disk to update the customer file). 

FIGURE 5 diagrams the local status input 
function for Add/Delete NEGATIVE status. A store uses 
this operation only for the negative status records for 
that location, and only when all bad checks have been 
recovered or otherwise resolved. For the Add NEGATIVE 
status function, . the corresponding negative status record 
for that location is retrieved or created (230), and 
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NEGATIVE status is set (232) Active and BAD 
Frequency/$Amount is adjusted (233) by adding the current 
bad check transaction. The corresponding customer record 
is then retrieved or created (235), and updated by the 
roll/update operation (238) but with status set (239) to 
NEGATIVE. 

For the Delete NEGATIVE Status function, the 
corresponding negative status record is retrieved (230), 
and NEGATIVE Status is set (232) to Inactive and BAD 
Freguency/$Amount are set (233) to zero. If that customer 
has no other bad checks outstanding at any location (i.e., 
no other negative status records with NEGATIVE Status 
Active) (236), then the corresponding customer record is 
retrieved or created (237) and updated by the roll/update 
operation (238), but with status rolled (239) to its 
previous state (i.e., prior to becoming NEGATIVE). 

For status input functions that Add/Delete CASH 
ONLY (which status is also kept by location in negative 
status file), the basic operation is the same as for 
Add/Delete NEGATIVE except that the BAD Frequency/$Amount 
data are unaffected. 

For the status input functions that Add/Delete 
STOLEN, only the customer file need be updated. For the 
Add STOLEN function, the corresponding customer record is 
updated in accordance with the roll/update operation, but 
with status rolled to STOLEN . For the Delete STOLEN 
function, the corresponding customer record is updated and 
rolled to CAUTION. 

For the user flag input functions that 
Add/Delete PREAPPROVED or MANAGER ONLY, again, only the 
corresponding customer record need be updated. 
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2.5. Global Update . For multiple-store systems, 
the global update function is used to coordinate the 
exchange of certain customer information among the 
individual stores. 

Global update is accomplished by file (record) 
transfers between each remote system and the host system. 
The host system receives selected customer records and 
negative status records from each remote, updates its 
customer database, and then transmits globally updated 
records back to each of the remotes. Each remote is able 
to maintain a local customer database, supplemented with 
selected global customer information deemed to be useful 
to all stores in the system. 

The type of customer information transferred by 
the global update function is based on store management 
policies. The recommended approach to exchanging global 
customer information is as follows: 

(a) Negative Status Records All NEGATIVE 
status records '(NEGATIVE or CASH ONLY status) 
accessed (created, or updated) since the last 
transfer; and 

(b) Customer Records All customer 
records with status values CAUTION, NEGATIVE, 
CASH ONLY and STOLEN accessed (created or 
updated) since the last file transfer; 

(c) POSITIVE status records (even those 
designated MANAGER ONLY) are not recommended for 
global transfer. 

As a result, the local customer database contains negative 
status records (including NEGATIVE and CASH ONLY status 
and BAD Frequency/$Amount ) for all store locations 
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(although each remote system only transfers to the host 
the negative status records for its location). For those 
customer records transferred, DWT Frequency/$Amounts can 
be maintained either globally or locally and globally. 
That is, a store may decide not to maintain both global 
and local transaction data since, for regular customers 
that primarily frequent that store (i.e., the customers of 
primary interest) global and local transaction data are 
essentially the same anyway. On the other hand, a store 
may want to keep its local transaction data completely 
separate from the global data attributable to all stores. 

The host/remote file transfers that support 
global update are accomplished automatically through the 
event/activity function described in Section 2.7. 
Generally, for each remote system, host/remote file 
transfer constitutes an activity automatically invoked at 
predetermined regular event intervals. This procedure 
insures that the local customer databases are regularly 
supplemented with globally updated status and other 
customer information affecting check verification. 

A global update session is initiated by a remote 
system. The remote transmits only those negative status 
or selected customer records accessed (updated) since the 
last host/remote file transfer. Since a remote only 
updates (or creates) negative status records for its 
location (although negative status records for other 
locations may be queried), a remote only transfers those 
local records (but will receive back from the host 
recently updated negative status records for all 
locations). And, only those updated customer records 
meeting the selected status criteria are transferred 
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(i.e., POSITIVE status records are not transferred, even 
if designated MANAGER ONLY). 

Negative status records are extracted using the 
index [ status/transf er/date/ID/location ] , while customer 
records are extracted using the index [ status/access 
date/ID]. 

FIGURE 6a diagrams the host global update 
function by which the host system receives recently 
updated negative status and customer records, and performs 
a global update of its customer database. For remote 
negative status records (remote location only), the host 
retrieves or creates (240) a corresponding host record, 
and sets (243, 244) host status (NEGATIVE/CASH ONLY, 
ACTIVE/ INACTIVE) and host BAD Frequency/$Amount equal to 
the corresponding remote values. For remote customer 
records, the host retrieves or creates a corresponding 
host record, and updates existing host records using the 
roll operation (246). Host and Remote status are 
compared, and if different, the host assigns status (247) 
according to predetermined status arbitration criteria. 
The host then adds (248) the Frequency/S Amount accumulated 
at the remote since last transfer to the Host DWT 
Frequency/$ Amount, and selects (249) the greater of 
host/remote DWT data as correct, updating the host record 
accordingly. 

After global update of the host customer 
database, the host transmits to the remote all negative 
status records and selected customer records accessed 
(updated) at the host since the previous transfer. 
Because every remote record transferred to the host caused 
a corresponding host record to be created or updated, and 
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therefore accessed, the host- to- remote file transfer 
necessarily includes all host records corresponding to the 
remote records transferred to the host during that 
session. In particular, host negative status records for 
all locations, meeting the recently accessed transfer 
criteria, are transferred to the remote. For negative 
status records from other locations, the remote merely 
copies (253) the host record (remote location records 
received from the host are necessarily the same as the 
remote record) . For customer records, the remote first 
rolls (254) the DWT Frequency and $Amount. If host DWT 
Frequency/$Amount is less than the corresponding remote 
DWT data (255), the remote rolls (256) access data to 
insure that the remote record is transferred back to the 
host during the next global update transfer session (to 
update the corresponding host record with the greater DWD 
data); otherwise, the remote selects (257) the host DWT 
data. That is, the global update function assumes that 
the greater DWT Frequency/$Amount is correct. Finally, 
the remote compares host/remote status, and if different, 
assigns status (258) according to predetermined status 
arbitration criteria. 

2.6. Purge . The customer database purge 
function allows a store to orient its customer database 
toward active customers, stabilizing the database size by 
deleting certain customer records and negative status 
records deemed to be obsolete. 

During database purge, customer records or 
negative status records with a given status are read, and 
the access data/time is compared with the corresponding 
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purge limit from the system control file. Records not 
accessed during the interval defined by the purge limit 



are deleted. 

Implementing the purge function is optional as a 
matter of store policy. For the preferred embodiment, the 
purge limits are also used to define a reset/CAUTION 
interval (described in connection with FIGURE 4). If a 
record is not accessed during that interval, its status is 
rolled to CAUTION. Thus, the check transaction processing 
system defaults to the reset/CAUTION operation if the 
purge function is not operational. 

The purge limits are a matter of design 
selection. The following purge limits are recommended: 



Because customer record status is not rolled automatically 
from CAUTION to POSITIVE, but only as a result of a 
transaction in which the access date/time is also rolled 
current, .the customer database maintains an accurate 
record of CAUTION status for those first-time customers 
who do not return after the check clearance interval. 
Those CAUTION status customers who do not return to a 
store within a reasonable period of time can be eliminated 
from the customer database. Likewise, POSITIVE status 
customers who stop transacting business with a store can 
be eliminated from the active customer database. 



CAUTION 



90 days 
180 days 
360 days 
360 days 
' 360 days 



POSITIVE 



NEGATIVE 



CASH ONLY 



STOLEN 
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Selected purge limits are entered into the 
system control file during system installation/ 
configuration. If the purge function is selected, 
performing it automatically as an event-driven activity 
(described in Section 2.7) is recommended. 

2.7. Event/Activities . Event-driven activities 
are performed automatically by the check transaction 
processing system to implement certain functions without 
operator intervention. 

The configuration and timing of these activities 
is a matter of routine design selection. The following 
event-driven activities, and the associated event 
intervals, are recommended: 

Host/Remote File Transfer Every 15 minutes 

System Backup Every 10 minutes 

Purge Every 24 hours 

In addition, certain report functions can be made 
automatic as event-driven activities, such as reporting 
every day all customer records with CAUTION or NEGATIVE 
status. 

The specified event-driven activities and 
associated event intervals are contained in an event table 
established during system installation/configuration. 
These activities are then executed in background at the 
designated event times without user intervention, and 
without affecting other foreground functions such as check 
verification. Once the event table is configured, the 
various activities may be started or stopped by invoking 
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appropriate functions from a transaction terminal 
(functions F950 and F951 in Table 4). 

For multiple-store systems, performing the 
host/remote file transfers necessary for global update on 
a regular, event-driven basis insures that CAUTION/ 
NEGATIVE status information for check verification 
purposes is kept current throughout the system. 
Performing such transfers at relatively short intervals 
keeps the individual host/remote communications sessions 
sufficiently short that other functions, such as check 
verification, are not significantly affected. Moreover, 
performing host/remote file transfers on a regular basis 
at short intervals helps guard against fraudulent bad 
check passing schemes. 

Regularly, purging the customer database 
facilitates database stabilization, and focuses the 
database on reasonably regular customers. The need for 
regular, and often, event-driven driven backup is obvious, 
and is not burdensome "Of system computing resources 
because only those customer records actually updated 
during the short interval between backup events need be 
backed up. 

2.8 Communications . The communications function 
is primarily used to support host/remote file transfers 
for global update in multiple-store systems. In addition, 
the communications function can be used for remote 
diagnostic operations. 

The communications function is implemented in a 
conventional manner. Both the implementation of the 
communications function and the mode of communications 



(such as using modem communications over dial up lines) 
are a matter of routine design selection. Implementing 
the communications function so as to be essentially 
"transparent to the local operation of the remote and host 
check transaction processing systems is recommended (see 
Section 3.6). 

2.9. System . Certain system diagnostic and 
system information functions are available to users of the 
check transaction processing system. 

y^. These system functions are not critical to the 
Anvontory^but are a matter of routine design selection. 
The recommended system functions are identified in 
Section 2.2 and Table 4, and include querying the customer 
database and system control file, obtaining disk usage and 
file size information, starting/stopping activities in the 
event file, and controlling certain keypad and modem 
configuration functions, as well as controlling certain 
system level functions such as log-on, log-off, open/close 
database, debug and system shutdown. In particular, these 
system functions are useful to store supervisory personnel 
for querying the customer database and for controlling 
event-driven activities, and to vendor support personnel 
for remote diagnostic purposes. 

2.10. Risk Management . The check transaction 
processing system enables a store to adopt a risk 
management approach to check verification. Specifically, 
through selection of the CALL MANAGER limits for each 
status (including POSITIVE) a store has considerable 
flexibility in adjusting its check authorization policy to 
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accommodate the different risks presented by different 
customers, both in terms of bad check risks and recovery 
risk. 

Adopting specific risk management procedures for 
check verification is a matter of. store policy implemented 
by routine design selection. . In addition to selecting -the 
CALL MANAGER transational limits for each status, the 
reset/CAUTION interval can be selected to force customers 
who do not return for that interval into a CAUTION status. 
Moreover, the user flags PREAPPROVED and MANAGER ONLY 

can be used to assign special check verification 
treatment to selected customers regardless of status or 
transactional (CALL MANAGER) limits. 

Adopting risk management approach to check 
verification through selecting transactional CALL MANAGER 
limits enables each store to make a policy decision about 
the degree of risk the store is willing to take within a 
given interval. Moreover, this approach can be tailored 
to the specific business climate of the store in terms of 
dollar volume, profitably, customer base and management 
philosophy. By specifying transactional CALL MANAGER 
limits in terms of status, frequency, dollar amount and 
transaction interval, the store's risk management approach 
to check verification can reflect statistical patterns for 
bad check/recovery risks. 

For example, frequency and dollar volume limits 
are important for the CAUTION status to reduce the risk 
that a store will be hit by a concerted bad check scheme. 
(Global update is particularly important in this area. ) 
Depending on past experience with its typical customer, or 
store policy, a new customer can be restricted in terms of 
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numbers of checks and/or dollar volume during the selected 
check clearance interval. 

Frequency and dollar volume limits are just as 
important for the POSITIVE status. A store shouldn't 
assume any significant risk in terms of dollar volume 
(either for a current trnasaciton or over a given 
relatively short interval such as a week) just because a 
customer has had one or a few checks clear. That is, 
total historical check transaction frequency is a 
significant factor in assessing the risk of cashing a 
given check; both in terms of likelihood that the check is 
bad and likelihood that a bad check will be recovered. 

2.11. Customer Information Reporting . The check 
transaction processing system allows a store to build and 
maintain a customer database containing customer 
information useful* for identifying new customers and 
developing customer profiles, in addition to its use for 
check verification. 

Reporting customer information, such as 
verification status and DWT Frequency/$ Amounts , is a 
matter of routine design selection and store policy. 

Customer information reports are recommended 
(a) to. identify new customers, and (b) to develop customer 
profiles, both of which can be used in targeting 
marketing, advertising and promotional programs, and for 
other customer relations purposes. Specifically, new 
customers are identified by regularly reporting customer 
records with a CAUTION status. Regular customers are 
identified by reporting customer records based on DWT 
Frequency data, while the level of a customer's business 
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is identified by reporting customer records based on DWT 
$Amount data. Additional customer information that can be 
readily collected in the customer records includes zip 
code and marital status information useful in demographic 
analysis. 

The check transaction processing system permits 
the customer . information contained in the customer 
database to be collected in an unobtrusive and efficient 
manner during high volume check transactions. 

3.0 PROGRAM DESCRIPTION 

The various check transaction processing 
functions described in Section 2.0 are implemented using a 
check transaction processing system ("CTPS" ) program 
executed by the transaction processor. 

The CTPS Program must implement several 
operations in real time: 

(a) transaction terminal network 
communications, including communicating 
verification requests and the corresponding 
responses; 

(b) database operations, including responding 
to verification requests and updating the 
customer database; 

(c) event-driven activities, including global 
update, which must execute in the 
background while the check verification 
function is executing; and 

(d) host/remote communications to support 
global update. 
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Moreover, while the purge function may be run after-hours 
as a batch operation, system backup should be executed at 
regular intervals throughout a business day as an 
event-driven background activity. 

To achieve acceptable performance using a 
286-class engine for the transaction processor, the 
preferred embodiment of the CTPS Program uses a 
multi- tasking architecture. The various functions 
performed by the CTPS Program are implemented as separate 
program tasks executed by the transaction processor in a 
multi-tasking mode. t For the preferred system 
configuration (described in connection with FIGURE 1), a 
multi-tasking architecture for the CTPS Program is 
superior in performance to available alternatives, such as 
polled interrupts. 

3.1. General . As shown in FIGURE 7, the CTPS 
Program includes various task programs interfaced through 
a System Kernal . Since the preferred MS/DOS Operating 
System is not multi-tasking, the System Kernal, is required 
to implement (.a) task switching, and (b) intertask 
communications. In this operating environment, the MS/DOS 
operating system is used only for disk file I/O, with the 
System Kernal interfacing functionally to the individual 
task programs as an operating system. 

System Kernal 400 controls task switching, 
intertask message communications (requests and responses), 
subtask spawning, and task synchronization using 
semaphores. 

Data Manager Task 500 controls all database 
operations used in check transaction processing functions 
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(such as verification with transactional update, query, 
local status update, global update and purge), executing 
function requests from the other task programs (such as 
the Terminal Manager Task and the Event Manager Task) and 
returning response data. 

Terminal Manager Task 700 controls data 
communications over the transaction terminal network, 
receiving function requests from the transaction terminals 
and spawning terminal request subtasks that transmit a 
request to an executing task (usually the Data Manager 
Task) and then build an appropriate response from the 
response data provided by that executing task. 

Event Manager Task 800 implements activities 
designated for automatic execution on an event-drive 
basis, such as host/remote file transfers for global 
update, spawning a background event subtask at the 
specified event time to execute the specified activities. 

Modem Manager Task 900 controls 
telecommunications primarily for host/remote file transfer 
for global update, but also for remote diagnostic 
purposes . 

In addition to these check transaction 
processing tasks, a Screen Manager Task 950 and a System 
Utilities Task 960 are provided for maintenance and 
diagnostic purposes. 

In general, for the Verify/Query and Local 
Status Update functions, the Terminal Manager Task 
sequentially polls the transaction terminals which enter 
and transmit requests, such as: 

Verify [Function Code/check ID/Function 
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Code/$Amount ] 
Query [Function Code/check ID] 
Add/Delete [Function Code/check ID/Status] 
For each terminal request, the Terminal Manager Task 
spawns a corresponding terminal request subtask that 
dispatches the request to a corresponding function/request 
routine, which sends the request to the Data Manager Task. 
The Data Manager Task executes the request, and notifies 
the function/request routine (by a semaphore operation) 
that response data is ready. The function/request routine 
then builds the appropriate response from the response 
data, and writes it into the terminal buffer for the 
requesting terminal. The Terminal Manager Task sends the 
response to the requesting terminal in the next polling 
sequence. 

For the Global Update function, the Event 
Manager Task running in a remote system sequences through 
an event table, and at specified event times and 
intervals, spawns a corresponding event substask to 
execute the global update activities, i.e., send/receive 
customer records and negative status records. The subtask 
dispatches to corresponding activity routines, i.e. 
activities that send/receive customer and negative status 
records. The send activity routines first request the 
remote Data Manager Task to retrieve records accessed 
since the previous global update, and then request the 
remote Modem Manager Task to transfer those records to the 
host Data Manager Task for global update. The receive 
activity routines first send requests for globally updated 
records through the remote Modem Manager Task to the host 
Data Manager Task, and then requests the remote Data 
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Manager Task to globally update the remote customer 
database using the records returned by the host. 

3.2. System Kernal . The System Kernal Program 
is implemented functionally by a multi- tasking module and 
a system services module. 

The multi-tasking module controls resource 
allocation through task switching, with multi-task 
execution being implemented using standard context 
switching to swap task instructions/data between (a) the 
program and data memory areas allocated to. the task; and 
(b) the task execution registers (i.e., the program 
counter, stack and other specified and general purpose 
registers). To implement intertask communications , the 
multi-task module allocates for each task data memory 
areas for request and response data, and maintains a task 
control block that contains for each task (a) task queues 
for intertask requests, and (b) semaphore flags. 

The system services module implements intertask 
communications through calls to the multi-task module. 
For intertask communication, the system services module 
implements semaphore operations on the allocated semaphore 
flags in the task control block. 

Functionally, the System Kernal interfaces to 
the various task programs that comprise the CTPS Program 
as a multi-tasking operating system. The Kernal performs 
four principal operations that establish a multi-tasking 
environment for the check transaction processing system: 

(a) task switching; , 

(b) task control block management for task 
queues and semaphores; 
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(c) intertask communication of task 
requests/responses using the task control 
block and allocated data areas; and 

(d) spawning subtasks. 

The first two operations are performed by the 
multi-tasking module, while the second two operations are 
performed by the- system services module. | In addition, 
the System Kernal manages the system control file, and 
performs diagnostic and system utility operations (these 
operations being implemented by the system services 
module) . 

The specific program implementation of the 
System Kernal is not critical to this invention, being a 
matter of routine design specification. Indeed, as 
described in Section 4.0. , the System Kernal can be 
replaced with a commercially available multi- tasking 
operating system. 

For the preferred embodiment, the muti-tasking 
module is implemented with a commercially available 
program, Time Slicer from Life Boat Systems. Time Slicer 
provides a conventional multi- tasking environment, 
including task switching (context switching) and task 
control block management (request queues and semaphore 
flags). These multi-tasking operations are implemented in 
a conventional manner. Alternative multi- tasking modules 
are commercially, available. 

At system initialization, the System Kernal 
allocates the task control block (queues anc^^^ wapli o me s 
flags) and the data areas for the various tasks. 
Thereafter, the System Kernal receives service requests 
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from a requesting task addressed to a responding task and 
written into the System Kernal's request queue. 

The requesting task builds a service request in 
the following format 

responding task ID 

requesting task ID 

function code 

address of request data 

address for response data 

stop^ semaphore 
The function code is one of the function codes set forth 
in Table 4. The addresses for the request and response 
data are data memory locations allocated to the requesting 
task. 

FIGURE 8 diagrams the intertask communication 
and subtask call functions implemented by the System 
Kernal. The System Kernal continually monitors (402) the 
request queue, executing service requests on a first-in 
first-out basis. The sys'tem kernal first determines (404) 
whether the next-in-line request is a service request or a 
subtask request from a requesting task, or a stop request 
(indicating request execution completed) from a responding 
task. 

In the case of an intertask service request, the 
system kernal builds (410) a corresponding intertask 
packet, and writes (412) the packet into the responding 
task queue in the task control block. In the case of 
subtask request (which includes the subtask file name), 
the System Kernal spawns (414) the specified subtask 
(which typically executes the called function using 
intertask service requests). In the case of a stop 
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request from a responding task, the System Kernal sets 
(416) the specified semaphone flag in the task control 
block, notifying the requesting task that request 
execution is complete and response data is ready. 

The intertask request packet built by the System 
Kernal is in the following format: 

requesting task ID 

function code 

address of request data 

address for response data 

semaphore flag 

That is, the intertask request packet includes the same 
information as contained in the service request from the 
requesting task, but without the responding task ID. That 
identification is unnecessary since each task is assigned 
a specific allocation of address space for its task queue 
and semaphone flags in the task control block, and for its 
data area. The stop request is the intertask request 
packet, which the System Kernal recognizes as a stop 
request when it appears in its request queue. 

In general, intertask request execution is 
accomplished as follows: Each task monitors its task 
queue in the task control block. If the task queue does 
not contain a request, the task continues executing 
internal functions. When an intertask request packet is 
written into a task queue by the System Kernal (in 
response to a service request), the responding task reads 
the packet from the queue. The responding task decodes 
the request packet, and dispatches the request to an 
execution routine (either directly or by first spawning a 
subtask that handles dispatching). This execution routine 
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reads the request data located in the requesting task 1 s 
data area, at the address specified in the intertask 
request packet, and executes the requested function using 
the request data. After request execution, the execution 
routine provides a response by writing response data to 
the specified address in the requesting task's data area, 
and sends a stop request (which is the intertask request 
packet) to the System Kernal indicating that request 
execution is complete and response data is ready. The 
System Kernal executes the stop request by setting the 
specified semaphore flag. 

For example, in the case of a verification 
request entered at a transaction terminal, the Terminal 
Manager Task spawns (through the System Kernal) a terminal 
request subtask. The terminal request subtask dispatches 
to a verification/request routine that sends a 
verification request through the System Kernal to the Data 
Manager Task. The Data Manager Task reads from- its task 
queue the verification request (i.e. the intertask 
verification/request packet), and determines that a 
verification function is requested. The Data Manager Task 
dispatches the request to an verification execution 
routine that reads the request data (check ID and $Amount) 
from the specified request data address, and performs the 
necessary customer database operations, including 
retrieving or creating a corresponding customer record and 
updating status and transactional data (DWT Frequency and 
$Amount) to reflect the current transaction. The 
execution routine then writes the updated customer record 
to the specified response data address, and sends a stop 
request (i.e., the intertask request packet) to the System 
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Kernal. The System Kernal sets the specified semaphore 
flag, and the terminal request subtask reads the customer 
record and builds an appropriate response that is sent to 
the terminal by the Terminal Manager Task. 

3.3. Data Manager Task . The Data Manager Task 
manages the customer database, maintaining the customer 
record file and negative status record file, and .the 
related indices. The Data Manager Task controls all 
database operations for check transaction processing 
functions (such as verify/query and local and global 
update) and customer database management functions (such 
as backup and purge), including record creation, 
retrieval, modification and deletion. 

The check transaction processing functions 
performed by the Data Manager Task are, generally: 

(a) Verify (with Transactional Update) 

(b) Query 

(c) Local Status Update 

(d) Global Update (Host and Remote) 

The verify, query, and local status update functions are 
invoked from a transaction terminal. The global update 
function is an activity invoked by the Event Manager Task. 

For the preferred embodiment, the Data Manager 
Tasks interfaces to the disk files (i.e., the customer, 
negative status and system control files) through a 
commercially available library of database management 
routines, C-Tree from Faircom Software. The C-Tree 
library, in turn, uses the MS/DOS File System (DFS) to 
handle disk file I/O. The configuration of those routines 
to operate with the Data Manager Task and the MS/DOS DFS 
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is a matter of routine design specification. Other such 
libraries of database management routines are commercially 
available . 

At system initialization, the Data Manager Task 
opens the customer and negative status files, and a 
password file (used for supervisor functions requiring a 
password) . 

FIGURE 9a is a program flow diagram for the Data 
Manager Task. The Task continually monitors (502) its 
task queue for requests (intertask request packets) 
written into the queue by the system kernal. These 
requests primarily involve database operations in 
connection with check transaction processing functions, 
and are received from the Terminal Manager Task 
( Verif y/Query and Local Status Update) and the Event 
Manager Task (Global Update, Purge and Backup). Some 
requests involve system diagnostic or information requests 
such as for disk or database information (see 
Section 2.2) . * 

If no requests are in the Data Manager Task 
queue, it executes internal functions (503). When the 
Task receives a request, it performs the following 
operations: 

(a) reading (506) a function request packet 
from the task queue; 

(b) decoding (506) the function code; and 

(c) dispatching (508) the function request to a 
corresponding function execution routine. 

The function execution routine executes the function, 
performing the necessary database operations, and upon 
completion, writes appropriate response data into the 
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location specified by the requesting task, and then sends 
a 'stop request (the intertask request packet) to the 
system kernal. 

The various functions identified in FIGURE 9A 
„ Verify (510)/ Host Global Update (Negative Status) 
(600), Host Global Update (Customer) (630), and Remote 
Global Update (660) are representative of the check 

transaction processing functions performed by the CTP 
Program. These functions, and the associated execution 
routines, are described in detail in connection with 
FIGURES 9B-9H. 

FIGURE 9B is a program flow diagram for the 
Verify routine in the Data Manager Task. After receiving 
and decoding the appropriate intertask request packet from 
the Terminal Manager Task, the Data Manager Task 
dispatches (508) to the Verify Execution Routine 510. 

The Verify routine reads (512) the verification 
request data (check ID and $Amount) from the request data 
location specified in the intertask request packet. The 
customer database is searched (514) using the check ID, 
and the corresponding customer record is retrieved (515) 
or created (516) with status set to CAUTION and DWT 
Frequency and $Amount set to zero. 

The Verify routine then calls (520) a roll 
routine that updates status and transactional data in the 
record to reflect the current access date/time. The Data 
Manager Task does not independently update customer 
records to make status and DWT Frequency/$ Amount reflect a 
current date/time. Rather, the customer records are 
updated in real time as they are accessed, such as during 
execution of verify and update functions. Because this 
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roll/update operation is used by many of the function 
execution routines in the Data Manager Task, a separate 
routine is provided and called by these routines. 

FIGURE 9c is a program flow diagram for the roll 
routine. The routine first rolls (522) the Access 
Date/Time in the customer record to the current date, and 
then calculates (524) the transaction interval, ie. the 
elapsed time since the customer's previous check 
transaction. 

The purge limit for the customer's status is 
read (526) from the system control file and compared (528) 
with the transaction interval. If the transaction 
interval exceeds the purge limit, a status .roll subroutine 
is called (530) and instructed to roll the status of the 
customer record to CAUTION. (This reset/CAUTION operation 
provides a default alternative to the purge function which 
would delete those customer records with access dates that 
exceed the corresponding status purge limit.) 

Next, the roll routine determines whether, for 
customer records with a CAUTION status, the predetermined 
check clearance period defined by the CAUTION/POSITIVE 
limit has passed. If the customer status is CAUTION 
(532), then the CAUTION/POSITIVE limit is read (534) from 
the system control file and compared (536) with the status 
change date, i.e., the date on which the customer became a 
CAUTION, either because of an initial check transaction or 
because of a roll to CAUTION (such as through the 
reset/CAUTION procedure in 526, 528 and 530). If the 
period during which the customer has been a CAUTION 
exceeds the CAUTION/POSITIVE period, then the status roll 
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subroutine is called (537) and instructed to roll customer 
status to POSITIVE . 

The roll routine then rolls (538) the DWT totals 
for both Frequency and $Amount to reflect the current 
access date. 

The customer record is now updated to the 
current access date, the roll routine having 
rolled/updated the Access Date/Time, Status and DWT 
Frequency and $ Amount. 

The status roll subroutine is called when any 
function routine rolls customer status from one value to 
another. As part of the call instruction, the status roll 
subroutine receives a new status, CAUTION in the case of 
the reset/CAUTION operation. Program state- logic then 
determines whether the roll is allowable according to 
specified roll state-logic: (a) if allowed, status is 
rolled to the specified new status; or (b) if not allowed, 
status is rolled to an allowable status value, or is not 
rolled, in accordance with the roll state-logic. The 
status roll subroutine then rolls the status change date 
in the customer record to the current date (if the 
subroutine effected a change in status). Thus, for 
customer records in which the transaction interval exceeds 
the status purge limit, the customer record is modified to 
reflect a CAUTION status with a corresponding status 
change date. 

The roll routine returns (539) to the calling 
routine, in this case, the Verify routine in FIGURE 9b. 
The verify routine adds (540) to the roll/updated customer 
record the current transaction by incrementing DWT 
Frequency and adding the current $Amount to the DWT 
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$ Amount. The customer record is now updated to reflect 
both the current . access date and the current transaction. 
The updated customer record (with its transfer date 
updated current) is written (542) to disk, to update the 
customer database. 

The updated customer record constitutes the 
response data for the verify request, and the Verify 
routine writes (544) the record into the response data 
location specified in the intertask request packet. 

Finally, the Verify routine sends (546) a stop 
request to the System Kernal. The stop request comprises 
the intertask request packet received from the System 
Kernal by the Data Manager Task. The appearance of this 
packet in the Kernal 1 s service request queue notifies the 
Kernal that request execution by the verify routine is 
complete. In response to the stop request, the System 
Kernal sets the semaphore flag specified in the intertask 
request packet to notify the Terminal Manager Task that 
the verification request is complete, and the response 
data is in the specified location. 

The query function is used to query the customer 
database, and retrieve an updated customer record or 
updated negative status record from which the desired 
information may be extracted. For each query function, 
the Data Manager Task dispatches to a corresponding query 
execution routine that retrieves and updates the requested 
customer record or negative status record. The essential 
difference between the query routines and the verify 
routine is that no current check transaction data is 
involved, and the updated record is not written to disk to 
update the customer database. 
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For example, in the case of a query for customer 
information (such as status and/or DWT transactional 
data), the Data Manager Task dispatches the intertask 
query request packet to the corresponding Query execution 
routine. The routine reads the check ID from the 
specified location for the request data, and initiates a 
search of the customer record file. If no corresponding 
customer record is found, the query routine returns an 
error message response. If a corresponding customer 
record is retrieved, the Query routine calls the roll 
routine to update Access Date/Time, Status and DWT 
Frequency/$Amount . The roll/updated customer record is 
written to the specified location for the response data, 
and a stop request is sent to the System Kernal. The 
Query routine does not update the customer database by 
writing the updated customer record back to disk. 

In addition to updating the customer database in 
real time through the verification operation, the Data 
Manager Task also implements the following local status 
update functions: 

Add/Delete NEGATIVE 

Add/Delete CASH ONLY 

Add/Delete STOLEN 

Add/Delete PRE APPROVED 

Add/Delete MANAGER ONLY 
These functions are used to input customer status and user 
flag information. 

For multiple store systems, negative status 
records are kept by location, i.e. each location creates a 
negative status record for any customer with NEGATIVE or 
CASH ONLY status at that location. Global Update causes 
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the negative status file at each location to contain 
negative status records for each location (assuming 
negative status records are selected for global update). 
Each location can access through the Add/Delete NEGATIVE 
and CASH ONLY functions only those negative status records 
for its location. The query function can be used to guery 
negative status records from other locations. 

FIGURE 9d is a program flow diagram for the add 
NEGATIVE local status update function. After receiving 
and decoding the appropriate intertask request packet from 
the Terminal Manager Task, the . Data Manager Task 
dispatches (508) to the Add NETATIVE execution routine 
(550). 

The Add NEGATIVE routine reads (551) the request 
data (check ID/location/$Amount ) from the location 
specified in the intertask request packet. The negative 
status file is searched (552) for a corresponding negative 
status record, which is either retrieved (553) or created 
(554). If NEGATIVE status is Inactive (556), the status 
roll subroutine in called (557) and instructed to roll to 
Active. The current bad check data is then added (558) to 
the BAD Frequency and $ Amount totals for that location. 
The routine then writes (559) the updated negative status 
record into the negative status file. 

The customer . file is searched (560) for the 
specified customer record, which is either retrieved (561) 
or created (562). The roll routine is called (564) to 
roll/update the customer record (Access Date/Time, Status 
and DWT Frequency/$ Amount ) as described in connection with 
FIGURE 9c. After roll/update, the status roll subroutine 
is called (566) and instructed to roll customer status 
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NEGATIVE. The updated customer record (with its transfer 
date updated current) is then written (568) into the 
customer file. 

After the add NEGATIVE function is accomplished, 
a confirmation response is written (570) into the 
specified response data location, and a stop request is 
sent (572) to the System Kernal (which sets the specified 
semophore flag) . 

FIGURE 9e is a program flow diagram for the 
delete NEGATIVE function. After receiving and decoding 
the appropriate intertask request packet from the Terminal 
Manager Task, the Data Manager Task dispatches (508) to 
the Delete NEGATIVE execution routine (580). 

For multiple-store systems, the Delete NEGATIVE 
function is used according to the following criteria: 
(a) it is only used to delete NEGATIVE status for the 
location requesting the delete NEGATIVE function; i.e., to 
change NEGATIVE status from Active to Inactive only in the 
negative status record 'for that location; and (b) it is 
only used if all bad checks for that location have been 
paid off or otherwise resolved. Thus, each location can 
only affect its own negative status record the global 
update function is used to distribute negative status 
records among all locations. 

The Delete NEGATIVE routine reads (581) the 
request data (check ID/location) from the location 
specified in the intertask request packet. The negative 
status file is searched (582), and the negative status 
record for that location is retrieved (584), if it exists. 
The status roll subroutine is called (586) to roll 
NEGATIVE status from Active to Inactive. The BAD 
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Frequency and $Amount data are then deleted (587) 
indicating that all bad checks have been paid or otherwise 
resolved . 

Next, the routine determines (590) whether 
another negative status record exists for that customer, 
i.e., whether the customer has a NEGATIVE status' active at 
other locations. If the negative status file contains no 
other negative status records for the customer, the 
customer file is searched to retrieve (592) the 
corresponding customer record. The roll routine is then 
called (594) to roll/update the customer record as 
described in connection with FIGURE 9c, and the status 
roll subroutine is called to roll status to the previous 
status (i.e., the customer's status prior to becoming a 
NEGATIVE). The updated customer record (with its transfer 
date updated current) is then written (596) to the 
customer file. 

After the delete NEGATIVE function is 
accomplished, a conf irmatich response is written (597) to 
the specified response data address, and a stop request is 
sent (598) to the System Kernal (which sets the specified 
semaphore flag) . 

The routines that Adding/Delete CASH ONLY 
operate analogously to the Add/Delete NEGATIVE routine 
because CASH ONLY is also maintained by location in a 
negative status record. These routines function in 
accordance with FIGURES 9d and 9e, except that transaction 
data (BAD Frequenc y/$ Amount ) is not involved (i.e., step 
558 is unnecessary) . 

The routines that Add/Delete STOLEN affect only 
the customer file. Thus, these routines read the 




79 



specified request data (check ID/status), and either 
retrieve or, for the add routine, create a corresponding 
customer record. The customer record is updated using the 
roll routine, and then rolled, to STOLEN (add function) or 
to CAUTION (delete function) using the status roll 
subroutine. The updated customer record is written to the 
customer file, and a confirmation response is written to 
the specified response data location. The routine 
terminates with a stop request sent to the System Kernal. 

The routines that Add/Delete PREAPPROVED and 
MANAGER ONLY operate to set/clear the corresponding user 
flags in the customer record in a manner analagous to the 
Add/Delete STOLEN routine. That is, these routines 
roll/update the corresponding customer record, set/clear 
the specified user flag, and then provide an appropriate 
confirmation response. 

For the' global update function, the host Data 
Manager Task receives negative status and selected 
customer records from ail the remote systems, and executes 
a host global update fundtion. Host negative status and 
selected customer records are then sent to the remote Data 
Manager Task which executes a remote global update 
function. The global update function is implemented by 
the remote Event Manager Task which executes a global 
update event/activity (see Section 3.5). 

The criteria for selecting records for transfer 
in connection with global update are: 



(a) Negative Status File — All records 
accessed since the previous host/remote file 



80 



transfer for global update (NEGATIVE or CASH 

ONLY status) ; and 

(b) Customer File All customer records 

accessed since the previous host/remote file 

transfer for global update, and having a status 

value of CAUTION, NEGATIVE,. CASH ONLY or STOLEN. 
Since a remote location only accesses (updates) the 
negative status records for its location, each remote only 
transfers to the host negative status records for its 
location. The host global update function necessarily 
accesses each negative status record transferred by a 
remote during a global update session, so that all such 
records are transferred back to each remote (along with 
the host location negative status records that were 
accessed as a result of local host operation. 

FIGURE 9f is a program flow diagram for the host 
global update function for the negative status file. 
After receiving and decoding the appropriate intertask 
request packet (containing the global update request from 
the remote Event Manager TAsk) , the host Data Manager Task 
dispatches (508) to the Host Global Update (Negative 
Status) execution routine 600. 

For each negative status record received (602) 
from a remote location, the host searches (604) its 
negative status file for a corresponding negative status 
record for that remote location. If it does not exist, the 
remote record is copied (607). 

If a corresponding host record is retrieved 
(606), the host NEGATIVE status (Active or Inactive) is 
replaced (608) with the remote NEGATIVE status from the 
remote negative status record, and the host BAD 
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Frequency/$Amount is replaced (610) with the remote BAD 
Frequency/$ Amount. The Access Date/Time is then rolled 
(612) current. 

The updated (or copied) host negative status 
record for the remote location is written (614) to the 
negative status file, and the negative status file is 
searched (616) to determine if it contains any NEGATIVE 
status Active records for that customer for any locations 
(including the remote negative status record just 
processed) . 

If not (i.e., if NEGATIVE status for that 
customer is Inactive at all locations), the corresponding 
customer record is retrieved (618) from the customer file. 
The record is updated by the roll routine (620), and 
rolled to previous status (622). The updated customer 
record (with its tranfer date updated current) is then 
written (624) back' to the customer file. 

The Global Update (Negative Status) routine 
terminates with stop request sent (626) back to the 
requesting remote Event Manager Task (see Section 3.5). 

FIGURE 9g is a program flow diagram for the host 
global update function for the customer file. After 
receiving and decoding the appropriate intertask request 
packet (containing the global update request from the 
remote Event Manager Task), the host Data Manager Task 
dispatches (508) to the Host Global Update (Customer) 
execution routine 630. 

For each customer record received from the 
remote (632), the host searches (634) its customer file. 
If a corresponding customer record does not exist, one is 
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created (636) with the local DWT Frequency/$Amount set to 
zero. 

If a corresponding host customer record is 
retrieved (635), it is updated (638) in accordance with 
the roll routine in FIGURE 9c. If status is CAUTION, 
POSITIVE or STOLEN, the status for the updated host 
customer record is compared (640) with the status for the 
remote customer record. If status is different, the host 
assigns (642) status in accordance with predetermined 
arbitration rules, and updates its customer record 
accordingly. (If either host or remote status is 
NEGATIVE, global update is accomplished through the Global 
Update routine for negative status records.) 

The host updates DWT Frequency/$Amount in the 
host customer record by adding (644) to the host DWT 
Frequency and $Amount the Transfer Frequency and $Amount 
totals from the remote customer record, and then selecting 
(646, 648, 649) the greater of the host or remote DWT 
Frequency/$Amount totals.' 

Finally, the host customer file is updated by 
writing (650) the host customer record (with its transfer 
date updated current) to disk, and a stop request is sent 
(652) to the remote Event Manager Task. 

. . Once the host has completed updating its 
negative status file (FIGURE 9f) and its customer file 
(FIGURE 9g) for each negative status and customer record 
transferred by the remote, the remote then requests that 
the host transfer to the remote the host negative status 
and selected customer records that have been accessed 
since the previous transfer. That is, the same criteria 
that the remote used in selecting records for transfer are 
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used to select host records for transfer back to the 
remote . 

Since, for each remote record transferred to the 
host, the host performs an update operation that changes 
Access Date/Time, the host-to- remote file transfer will 
necessarily result in all such updated records being 
retransmitted back to the remote. In addition, the host 
will transfer to the remote NEGATIVE status and selected 
customer records accessed and updated by the host during 
either (a) local-host verification or update operations, 
or (b) a host g-lobal update operation initiated by another 
remote. 

The .remote receives the negative status and 
customer records transferred from the host, and performs a 
global update. of its customer database. As described in 
Section 3.5, the remote Event Manager Task requests host 
records from the host Data Manager Tasks, and then sends 
them to the remote Data Manager Task with a global update 
request. ' 

The remote global update function for the 

negative status file is based on two criteria: (a) for 

remote- location negative status records^ the remote record 

is assumed to be correct and the.fcaSl^t* record is ignored; 

A 

and (b) for other-location negative status records, the 
host record is assumed to be correct and it is copied 
without any update or other access by the remote. After 
receiving and decoding the appropriate intertask request 
packet (containing the global update request for the host 
negative status record from the remote Event Manager 
Task), the remote Data Manager Task dispatches to the 
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Remote Global Update (Negative Status) execution routine 
that implements these global update operations. 

FIGURE 9H is a program flow diagram for the 
remote global update function for the customer file. 
After receiving and decoding the appropriate intertask 
request packet (containing the global update request from 
the remote Event Manager Task), the remote Data Manager 

TAOTy dispatches (.508) to the Remote Global Update 

r 

(customer) execution routine (660). 

For each customer record received (662), the 
remote determines (664) whether it has a corresponding 
customer record, and if not, creates (666) one with the 
local DWT Frequency and $Amount data set to zero. An 
existing remote customer record is retrieved (665), and 
DWT Frequency/$Amount rolled (668) current. The remote 
then compares (670) its global DWT Frequency/$Amount with 
the corresponding totals from the host customer record, 
and if the remote totals are greater, rolls (672) the 
Access Date/Time currerft. Updating the Access Date/Time 
for the customer record insures that that record will be 
transferred back to the host during the next remote/host 
file transfer session.' If the host transactional data is 
greater, then the Access Date/Time is not changed. 

If status is CAUTION, POSITIVE or STOLEN, the 
status for the updated remote customer record is compared 
(674) to the host customer record status, and if 
different, the remote assigns (675) status in accordance 
with predetermined arbitration rules. (If either host or 
remote status is NEGATIVE, global update is accomplished 
through the host global update function for negative 
status records.) 



I 
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The updated customer record (with its transfer 
date updated current) is written (676) to the customer 
file, and a stop request is sent (678) to the host System 
Kernal . 

The arbitration rules used by the host during 
global update, to assign status (642 in FIGURE 9G and 675 
in FIGURE 9H) for customer records in the case of a 
conflict between host and remote status are a matter of 
design choice and routine program implementation. The 
recommended criteria for specifying arbitration rules are 
(a) where either the host or the remote indicates POSITIVE 
and the other . indicates CAUTION, the POSITIVE status value 
is selected;- (b) where either the host or the remote 
indicates STOLEN, the STOLEN status is selected; and 
(c) NEGATIVE status is not arbitrated. 

The database operations associated with purge 
and backup are also handled by the Data Manager Task. 
These functions are implemented as event activities by the 
Event Manager Task. In' response to requests ^fro mtho - 
corresponding event activity routine, the Data Manager 
Task retrieves the specified records and processes them in 
accordance with conventional record delete (purge) or copy 
(backup) operations. Thus, for backup, the Event Manager 
Task provides a backup key [status/access date/time], and 
all records accessed since the last backup are copied to a 
backup file. For purge, a purge routine operates 
analogously to the roll routine (FIGURE 9c) in reading 
purge limits from the system control file and comparing 
them against a purge interval defined by the last access 
date/time, deleting (or copying off-line) those records 
that meet the predetermined purge criteria. 
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3.4. Terminal Manager Task . The Terminal 
Manager Task . manages the communication of 
requests/responses between the transaction terminals and 
the transaction processor, implementing a token ring local 
area network. In implementing token ring data 
communications, the Terminal Manager Task sequentially 
polls each transaction terminal using the token ring 
protocol described in Section 1.2. 

When request data (such as check ID/$Amount) are 
entered into a transaction terminal, the transaction 
^£er,minal responds to its next POLL token by transmitting 
•TXDATA answer packet including the request to the Terminal 
Manager Task, which writes the request data into the 
corresponding terminal buffer. 

For each request received from a transaction 
terminal, the Terminal Manager Task spawns a terminal 
request subtask that: 

(a) Builds a System Kernal service request for 
the request entered into the transaction 
terminal; 

(b) Sends the service request to the responding 
task through the System Kernal; 

(c) Receives response data from the responding 
task; 

(d) Builds the appropriate response from the 
response data; and 

(e) Sends the response to the transaction 
terminal . 

The responding task depends upon the request function code 
entered into the termina. (See Section 2.2) Most of the 
request functions are for the Data Manager Tasks because 
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they involve customer database access. However, requests 
to the other. tasks for diagnostic or system information 
can be made from a transaction terminal. 

At system initialization, the Terminal Manager 
Task: (a) Initializes the 32-port network communications 
interface (116 in FIGURE 1A); (b) Allocates TXBUFFER, 
RXBUFFER and LASTDATA terminal buffers for each of 32 
allowable terminals; and (c) Allocates two poll state 
flags, Poll/Data and Wait, for each of 32 allowable 
terminals. The TXBUFFER buffer holds TXDATA transmitted 
by the terminal, while the RXBUFFER buffer holds RXDATA to 
be sent to the terminal. The LASTDATA buffer contains 
selected data from the last request transmitted by or the 
last response received by the terminal (used to hold data 
that might be used in the next terminal request). 

For the. preferred embodiment, no attempt is made 
to deallocate "terminal buffers/flags for those 
communications ports that do not have an active, on-line 
transaction terminal. This design choice does not require 
any significant memory allocation for the 32-terminal 
configuration of the preferred embodiment. Such 
deallocation procedures are a matter of routine program 
implementation . 

FIGURE 10A is a program flow diagram of the 
token ring network communication function implemented by 
the Terminal Manager Task. 

The Terminal Manager Task continually monitors 
(702) its task queue, which is maintained by the System 
Kernal. Through the System Kernal, system and diagnostic 
requests can be written into the queue for execution by 
the Terminal Manager Task. That is, in response to a TMT 
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request (such as a system diagnostic or system information 
request) written into its queue, the Terminal Manager Task 
calls (703) a corresponding routine that executes the 
request. 

If no TMT request has been written into the task 
queue, the Terminal Manager Task begins a token polling 
sequence (704, 706). 

A token polling sequence is accomplished by 
sequencing through the terminal addresses 0-31. During 
each polling sequence the Terminal Manager Task polls all 
32 ports without regard to whether a port has an active, 
on-line transaction terminal coupled to it, provided 
however, that an active terminal in a Wait state (i.e., 
waiting to receive requested data) is not polled. 

The Event Manager Task makes no attempt to 
segregate active and inactive communications ports, or to 
remove from the polling sequence terminal addresses not 
assigned to active, on-line transaction terminals. This 
design choice does not significantly impact network 
communications for the 32 terminal configuration of the 
preferred embodiment. An active-terminal-only pulling 
scheme would be a matter of routine program 
implementation. 

Terminal addresses are determined as follows. 
During each polling sequence, the Terminal Manager Task 
polls each of the 32 ports — beginning with Port 0, a 
POLL token (including the corresponding terminal address 
between 0 and 31) is broadcast and the Task waits until 
either (a) an answer packet is received, or (b) a time-out 
period transpires, before sending the next POLL. When a 
transaction terminal signs on, its internal network 
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communication software causes an [ENTER TERMINAL ID] 
message to be displayed. The terminal' operator is 
supposed to enter a number between 0 and 31 that is 
uniquely assigned to that terminal; however, the internal 
software processes the terminal ID entry using wedtr±i^31 , 
so that any numeric entry is forced into the 0-31 range. 

For each terminal address the Terminal Manager 
Task determines (710) the polling state of the 
corresponding transaction terminal Poll, Wait, or Data. 

If the terminal is in the Poll state, the 
Terminal Manager Task sends (712) a POLL token for that 
transaction terminal (i.e., a token that includes the 
corresponding terminal address). The POLL is received by 
the addressed terminal, and recognized as an invitation to 
transmit data. The polled terminal transmits either a 
TXDATA answer (including request data) or a NODATA answer. 
If a NODATA answer' is returned (714), the Terminal Manager 
Task continues with the polling sequence. If the polled 
terminal transmitted request data in TXDATA answer (715), 
the Terminal Manager Task writes (716) the- request data 
into the corresponding terminal buffer, sets (718) the 
terminal Wait state flag, and spawns (720) a terminal 
request subtask to execute the request, and then continues 
the polling sequence. 

During execution of the request, while the 
requesting terminal is in the "Wait" state, the Terminal 
Manager Task does not poll that terminal, but rather, 
continues with the polling sequence. 

Once a request has been executed and the 
response data placed in the terminal buffer for the 
requesting transaction terminal, the request subtask sets 
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the terminal Data state flag. _ During the next poll 
sequence, the Terminal Manager Task reads (722) the 
response from the terminal buffer and sends (724) an 
RXDATA token that includes the response. 

When the token poll sequence is completed (i.e., 
terminal address 31), the task queue, is checked (702) to 
determine whether any system or diagnostic TMT requests 
have been written into the queue. If not, a new polling 
sequence is commenced (704). 

When the operator enters the terminal ID, the 
network software watches for that terminal address when 
a POLL with that address is received, the network software 
waits for a time-out to determine whether another terminal 
has that address. If not, the network software grabs the 
next POLL with that address and commences normal network 
communications . 

For the preferred embodiment, the POLL token is 
one byte (0-7) : 

Bit 7 Token Flag (set if POLL token; 

otherwise clear) 

Bits 5-6 TX-POLL token 

RX- RXDATA token 

y 

Bits 0-4 Terminal address 

All data communications over the network are in 7 bit 
ASCII (0-6), so that only the POLL token uses bit 7. The 
answer packets are also one byte: 
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Bit 7 Not used 

Bits 0-6 TXDATA 
* NODATA 

The TXDATA byte is followed by up to 40 characters of data 
in 7-bit ASCII (0-6), with a single END of data byte 
(ASCII carriage return) . Finally, the RXDATA token [Token 
Flag Set/RX/Terminal Address] is followed by up to 40 
characters of data, with the next POLL token designating 
END of data. 

Thus / in operation, a transaction terminal 
watches the network for its POLL token (with its terminal 
address). When its POLL is received it sends back either 
a NODATA answer byte, or a TXDATA byte followed by up to 
40 characters of data terminated in an END character. If 
the terminal is waiting for response data, so that it: has 
been placed in a Wait state, it will not receive a POLL 
token. When response dkta is available, the Terminal 
Manager Task will retrieve the data from the terminals 1 
RXBUFFER and transmit it with the next TXDATA token. 

This implementation for a token ring network is 
a matter of design choice. Other implementations are a 
matter of routine program design. Commercial token ring 
program packages are available. 

To execute a request sent by a transaction 
terminal during a polling sequence, the terminal request 
subtask first determines which function is requested, and 
then dispatches to an appropriate service request routine 
that: 
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(a) Builds a service request; 

(b) Sends the service request to the responding 
task (via the. System Kernal); 

(c) Builds an appropriate response from the 
response data returned by the responding 
task; and 

(d) Writes the response into the appropriate 
terminal buffer. 

In addition, for a verify request, the verify service 
request routine determines whether any "CALL MANAGER" 
limits have been exceeded, and if so, causes the "CALL 
MANAGER" . response to be returned to the terminal. 

From Section 3.2, a service request is in the 
following format: 

Requesting task ID 

Responding task ID 

Function code 

Address of request data location 
Address for response data location 
Semaphore flag 

The service request is sent to the System Kernal, which 
builds a corresponding intertask request packet. 

The responding task that executes the request 
depends upon the function code. Of course, most function 
codes will be executed by the Data Manager Task because 
they involve accessing in some way the customer database. 

After execution of the request, the response 
data returned by the responding task depends upon the 
request function code. The Data Manager Task returns 
updated customer or negative status records in response to 
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verify/query requests and confirmations in response to 
local status update functions and global update functions. 

Exemplary terminal request subtask operation is 
described in connection with a verify request in which the 
responding task is the Data Manager Task. 

FIGURE 10B is a program flow diagram for a 
terminal request subtask that implements a verification or 
query status request, to which the response from the Data 
Manager Task is an updated customer record. The subtask 
first reads (732) the TXBUFFER terminal buffer for the 
transaction terminal, parses (734) the request data to 
identify the function code (verify) and the other request 
data (check ID and $ Amount ) . 

The subtask then dispatches (736) the request to 
a verify service request routine specified by the verify 
function code. 

The service request subroutine builds (740) an 
appropriate service request addressed to the Data Manager 
Task^Tesponding task), which is sent (742) to the System 
Kernal . 

The terminal request subtask then suspends 
execution and monitors (744) the semaphore flag specified 
in the service request. The semaphore flag is set by the 
System Kernal in response to a stop request from the Data 
Manager Task, indicating that the request has been 
executed and response data (a customer record) written to 
the response data location specified in the service 
request. 

The terminal request subtask then reads (746) 
the response data, and builds an appropriate response for 
the requesting terminal. For the verify (and query 
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status) requests, the corresponding service request 
routine builds a response from the customer record 
(response data) only after testing (750) corresponding 
user flags and CALL MANAGER limits. These user flag and 
CALL MANAGER operations are not required for other 
function service requests (such as query negative, local 
status update or global update). 

The first operation in building an appropriate 
verification response from the customer record returned by 
the Data Manager Task is to test the MANAGER ONLY flag 
(752). If that flag is set, the verify service request 
routine builds (754) a MANAGER ONLY response regardless of 
customer status, and without testing any CALL MANAGER 
limits. 

If the MANAGER ONLY user flag is clear, the next 
operation is to test the PREAPPROVED flag (756). If the 
flag is set, and "customer status is POSITIVE (758), a 
normal (i.e. PREAPPROVED) response is built (762) without 
regard to any CALL MANAGER limits. If customer status is 
other than POSITIVE, the PREAPPROVED flag is ignored and 
CALL MANAGER limits are tested. 

After testing the user flags, the next operation 
in building a response for a verify request is to test the 
CALL MANAGER limits (760) for the customers status and DWT 
data. The DWT Frequency/$ Amount CALL MANAGER limits 
appropriate for the customer's status are read from the 
system control file and compared with DWT Frequency and 
$ Amount from the customer record. If any CALL MANAGER 
limit is exceeded, . CALL MANAGER RESPONSE is built (764) 
regardless of status. If no limits are exceeded, the 
normal response for that status is built (762). 
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As described in Section 2.3 and 2.10, the CALL 
MANAGER limits are used to place predetermined 
transactional limits (DWT Frequency/$ Amount ) on a check 
transaction primarily for customers with CAUTION and 
POSITIVE status. These limits are set as a matter of 
store policy, and placed in the system control file during 
system configuration. 

For function requests other than verify and 
query status, the user flag and CALL MANAGER operations 
(750) are not included in the service request routine, and 
a normal response is automatically built (762) from the 
response data read (746) from the specified response data 
location. 

The response MANAGER ONLY, PREAPPROVED , CALL 
MANAGER or [Normal] is written (766) into the 

appropriate terminal buffer, and when the terminal's 
RXBUFFER buffer is full, the terminal Data state flag is 
set (768) to indicate that a response is in the terminal's 
RXBUFFER buffer and shourld be sent to the terminal in the 
next polling sequence. The terminal request subtask then 
terminates (770). 

The basic operation of the terminal request 
subtask for each request function is as described in 
connection with FIGURE 10B for the verify request, except 
that the service request routines for request functions 
other than verify do not implement the user flag or "CALL 
MANAGER" response functions (750). 
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3.5. Event Manager Task . The Event Manager Task 
manages background activities that are executed 
automatically without operator intervention, maintaining 
an Event File that includes an Event Table, an Activity 
Table and associated indices. The Event Table includes 
event records each specifying an event time, an event 
interval and associated activity pointers into the 
Activity Table. The Activity Table includes a list of 
activity codes. 

The basic activities implemented by the Event 
Manager Task are: 

(a) Host/Remote Communications These 
activities transfer customer records and 
negative status records between host and 
remote systems for global update; 

(b) Purge These activities, one for each 
status, delete customer records and 
negative status records that are obsolete 
based on 'specified purge limits contained 
in the system control file; and 

(c) Backup — These activities are regularly 
invoked to backup the customer and negative 
status files. 

The host/remote communications and backup activities 
operate only on those customer records or negative status 
records that are accessed (i.e., that have their transfer 
dates updated) after the last corresponding activity was 
performed. Host/remote communications are implemented in 
connection with the Modem Manager Task. 

The Event Table contains an event record for 
each event, with each event record including: (a) an 
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event interval specifying the interval between execution 
of the associated event activities; (b) the next event 
time, calculated by the event subtask after completing 
execution of an event/activity based on the event interval 
and the system clock; (c) up to 10 activity pointers into 
the Activity Table; (d) active/inactive flag set or 
cleared by a start/stop function request (F950 and 951 in 
Table 4); and (e) diagnostic abort flag that is tested 
during event/activity executin by the event subtask, and 
can be used to abort an event/activity. 

In its basic operation, the Event Manager Task 
sequences through the events (event records) in the Event 
Table, spawning a corresponding event subtask to execute 
the specified activity. 

Event/activities are started and stopped using a 
transaction terminal to enter a corresponding request (see 
the function codes' 950 and 951 described in Section 2.2 
and set forth in Table 4). After entry of a start/stop 
request at a transaction* terminal, the Terminal Manager 
Task (terminal request subtask) addresses a service 
request to the Event Manager Task through the System 
Kernal. The Event Manager Task receives the service 
request from its task queue, executes the request by 
correspondingly modifying the event file, and returns an 
appropriate response to the Terminal Manager Task. 

While event frequency for a given activity is a 
matter of store policy and design choice, typically, 
host/remote communications and backup will be performed 
fairly frequently to insure both the regular update of the 
customer database, and the ability to recover from a 
system failure without significant loss of data. On the 
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other hand, the purge function is more a matter of system 
administration designed to control the size of the 
customer database. Indeed, the purge function can be 
omitted as an event activity. In that case, the status 
purge limits contained in the system control file define 
the reset/CAUTION interval used in ; the roll routine to 
roll all statuses back to CAUTION if the specified 
reset/CAUTION (i.e., purge) limits are exceeded, as 
described in connection with FIGURE 9b. 

The selection and timing of event-driven 
activities is a matter of design choice. The recommended 
event-driven activities, and the associated event 
intervals, are: , t 

Host/Remote File Transfer Every 15 minutes 

System Backup Every 10 minutes 

Database Purge Every 24 hours 

The Event Manager Task sequences through the 
event file, selecting the specified event-driven 
activities on a read-next basis. Event times are 
specified as time intervals starting from a baseline 
system time 00:00:00:00:00:00 [ yymmddhhmmss ] for 
January 1, 1970 (the transaction processor .includes a 
battery assisted hardware clock synchronyzed to this 
baseline system time). 

When an event time is reached / and the 
associated activity is completed, the event time is 
incremented by the event interval, based on the previous 
event time and not on when the activity was actually 
completed. For example, if host/remote file transfers to 
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support global update activities (i.e., transfers of 
negative status records and selected customer records are 
to be accomplished every 15 minutes, then each activity is 
entered into the event file with an interval of 
15:00[mmss]. The activity will be entered into the event 
file, along' with its event interval and its initial event 
time of 15 minutes after system initialization (assumed to 
be 00:00[mmss] ) . The activity will then first be executed 
at 15:00, and when the activity is completed, the 
associated event time will be incremented to 30:00. 

At initialization, the Event Manager Task opens 
the Event Table and Activity Table, and clears all 
semaphore flags. Thereafter, the Event Manager Task 
sequences through the Event Table, spawning event subtasks 
at specified event times to execute corresponding 
activities. While a given event may have several 
activities associated with it, only one event subtask (and 
only activity within an event record) is executed at a 
time. ' 

FIGURE 11A is a program flow diagram for the 
Event Manager Task. The task continually monitors (802) 
the Event Manager Task queue, to determine if any EMT 
requests have been received from the System Kernal. These 
requests may be for diagnostic or system information 
purposes. If so, the appropriate system routine is 
executed (804) . 

If the task queue is empty, the Event Manager 
Task tests the event-active semaphore (810) to determine 
whether an event is active. If so (semaphore set), the 
task checks the task queue (802). 
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If no event is active (semaphore clear), the 
Event Manager Task reads (812) the next event record from 
the Event File, and compares (814) the event time in the 
event record with the current system time. If the event 
is greater than or equal to the system time, the Event 
Manager Task spawns (816) an event subtask to execute the 
activities associated with the event (sending a subtask 
request to the System Kernal). 

The Event Manager Task then the task, reads (812) 
the next event/activity from the event file. 

If the event time for the next event/activity is 
greater than or equal to the current time (814), the Event 
Manager Task spawns (816) an Event Subtask to execute the 
event/activity. 

FIGURE 11B is a program flow diagram for the 
event subtask. At the appropriate event, time, the Event 
Manager Task spawns the event subtask, which receives 
(822) the current event record from the Event Table. The 
current event record includes a current event time and an 
activity pointer to each of up to 10 associated activities 
identified in the Activity Table. The event subtask 
sequentially executes each activity associated with the 
current event time. 

Event subtask operation will be described in 
connection with executing at a remote system the 
activities associated with the global update function. 
Specifically, the event subtask will be described in 
connection with sequentially executing the following 
global update activities: 

(a) Originate call; 
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(b) Send customer records (all selected 
statuses); 

(c) Send negative status records (NEGATIVE 
and CASH ONLY) ; 

(d) Receive customer records (all selected 
statuses); and 

(e) Receive negative status records 
(NEGATIVE and CASH ONLY) . 

That is, each of the send/receive activities reads all 
selected statuses. When the remote event subtask receives 
the event record containing the event time pointers into 
the Activity Table, it sets (824) the event-active 
semaphore (810 in FIGURE 11a), preventing the Event 
Manager Task from spawning another event subtask. The 
subtask then initiates an activity sequence (826, 828). 
Using the activity pointer in the Event Table, the subtask 
sequentially read's (826) activity codes from the Activity 
Table. The activity codes are read on a read-next basis, 
with each read operation being tested to determine when 
the last activity in the sequence is completed (828). 

For each activity code read from the Activity 
Table, the event subtask dispatches (830) to a 
corresponding activity routine for execution. 

Each activity routine includes an activity data 
control data block containing certain fixed and/or 
variable data used by the routine in executing the 
activity. Thus, for the global update event, the 
originate call routine includes in its activity control 
data block the phone number for the host (as well as other 
system numbers that may be called by the remote) and a 
corresponding log-in ID. The send/receive record routines 
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include in their respective activity control data blocks 
the previous event time for the activity which defined the 
end of the previous event interval for that activity. 

Thus, the current event interval for a global 
update (send/receive) activity is defined by the previous 
event time in the activity routine's .control data block, 
and the current, event record. After execution of the 
activity, the current event time is written into the 
activity routine's control data block to define the 
beginning of the next global update event interval. (A 
similar control data block operation is used for the 
backup activity. ) 

A global update event begins at a remote system 
with an originate call activity that directs the remote 
Modem- Manager .Task (MMT) to establish a communications 
link to the host. This activity is dispatched to an 
originate call routine (840) for execution. 

The.origi^e^lX ( ro^ine^ins by building 
and sending to the remot^-MM? a ifegufest. (842) to dial the 
host -- the^^reguest includes a dial function code and 
the request data location into which the originate call 
routine writes the host telephone number, together with a 
specified semaphore fla^^o^n^te^all routine 
waits on a response from the^^MT (843), periodically 
testing the stop se^h^^^^^n^h^ specif ied 
semaphore flag is set by the^WOS^ indicating that the host 
has been dialed and is in an off-hook condition opening a 

communications ^^^^^J^^^^^ C *^~/0$t?* builcis and 
sends to the remoEe^ a log-in 

ID to the host MM¥^w^€in?^^ a specified 

request data location. The originate call routine then 
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waits on the specified stop semaphore flag being set 

(845). When the s P^£^ ie f^P ema V ho ^jJ^ g is set/ 
indicating that the ^Sfo^wwT ^ha^corripleted log-in to the 
host system and established an active communications link, 
the originate call routine terminates by setting (846) a 
modem flag to indicate that a communications link is 
active, and then returns (826) to the event subtask for 
execution of the next activity. 

The event subtask reads (826) the code for the 
next activity in the global update activity sequence 
the send customer record activity. 

The event subtask dispatches (830) to the 
corresponding send customer record .routine (850). The 
routine first reads (852) the previous ending event time 
from its control data block to provide an initial customer 
record retrieval key to be used by the remote Data Manager 
Task (DMT) to retrieve a customer record from the customer 
record file. The retrieval key includes two fields [check 
ID/transfer date/time] --'each is used by the Data Manager 
Task to sequence through the customer record file 
(incrementing check ID first and then transfer date/time). 

The fg££ customer ^jpec^d routine builds and 
sends to the ^f^a r^ie^t 4 854) to retrieve by the 
retrieval key the first customer record meeting the 
criteria for transfer to the host during the current 
activity « any customer record that was accessed 
(updated) during the current event interval at any time 
after the time specified in the retrieval key (initially, 
the ending time for the immediately preceding event 
interval during which customer records were transferred to 
the host). The routine writes the initial retrieval key 
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(with check ID set to zero) into the specified request 
data location to provide the DMT with the initial customer 
record retrieval key for the current event interval. The 
send customer record routine then waits ( 855 £2,.^®^ 
specified stop semaphore flag bging set by the 

Thfc^S& 4 r e l ce^es'^he initial customer record 
C *~" retrieval request, and dispatches it to a corresponding 
customer record retrieval routine. This routine reads the 
initial record retrieval key (including the ending time 
for the previous event interval which is the beginning 
time for the current event interval) from the specified 
request data location, and using this initial key and the 
index [ status/transfer date/check ID], retrieves the first 
customer record with an access date/time equal to or 
greater than the beginning event time (if more than one 
customer record has the same access date/time, then the 
customer.^ecA^^th the_lc^est check ID is retrieved). 
When thep^^retr^\rll ^ou^ine has retrieved this first 
customer record in, the current event interval, it provides 
an appropriate response to the send customer record 
routine, writing the retrieved customer record into the 
specified response data location and sending a stop 
request to the System Kernal. 

When the stop semaphore is set (855), the send 
customer record routine reads the retrieved customer 
record from the spec if^eg, response jia,ta location, and 
determines (858) that^ ?he W^Ks returned a customer 
record. The routine then extracts (859) the transfer 
date/time and check ID from the retrieved customer record, 
and determines (860) that the current event time, which 
defines the end of the current global update event 
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interval, is greater than the transfer .date/time for the 
retrieved customer record, thereby confirming that the 
retrieved customer record was accessed during the current 
event interval. 

The send customer record routine then ysends a 
global update service request tcrthe _ no s-Kffi?; along with 
the iustr retrieved rempta customer . record, through the 
remote*MM^ routine then waits (863) on the 

specified stop request being se ffi<,$^S%? with ^^33^ n ^ e 



(acknowledgement)^ ^A^f^^^^ thf ougfv/the'host — 

and the remo ? te7lS& ^©/^respectively , the remote System 
A. 

Kernal and the specified response data location in the 
data area for the remote event subtask. 

The above remote/host intertask communication 
operation is described in greater detail in Section 3.6 
(Modem Manager Task).. Essentially, .the Modem Manager Task 
is designed so that remote/host intertask communications 
is essentially transparent to the requesting and 
responding tasks. That * is, the remote/host requesting 
task sends a service request with request data and a stop 
semaphore to its System Kernal addre^ss^d^to e^^L^T^u^ 
host/remote responding task. The remote/host MM^s- provide 
an essentially transparent communications link between the 
remote/host System Kernals to. effect the return of the 
stop semaphore and response data from the host/remote 
responding task to the remoteyhost requesting task. 

When the send customer record routine detects 
(863) the specified^to^ semaphore f l3^be^ing set, it 
requests (854) the °6^3*Wzt}&d? next customer 
^1/ record in the current global update event interval, 
writing the transfer date/time and check ID extracted 
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(859) from the just-sent customer record into a request 
data location to provide a new retrieval key for the DMT. 

As with the first customer record retrieved in 
the current event interval, the TaWT^ dispatches this 
request to a customer record retrieval routine that reads 
the new retrieval key from the . specified request data 
location, and using the index [ status/transfer date/check 
ID], searches the customer, file by incrementing first 
check ID and then transfer date/time until the next record 
is retrieved. The DMT retrieval routine then responds to 
the customer record retrieval request, writing the 
retrieved customer record into the specified response data 
location for the send customer record routine. 

This procedure requesting a customer record 
using the transfer date/time, and check ID for the previous 
record as the retrieval key, retrieving that customer 
record by reading 'the custpmer file using the retrieval 
key, sending the retrieved, customer record to the host, 
and requesting the nex t^^cp^ o r^^^c on ti nue s until 
either (a) the remote t j^W-^spond]sto a retrieve customer 
record request from the send customer record routine by 
indicating that the customer file contains no other 
customer records accessed- after the just-sent customer 
record (as detected in step 858), or (b) the send customer 

record routine determines that the customer record 

retrieved by the -DMT^ has a transfer date/time after the 
current event time (which defines the end of the current 
global update event interval as determined in steps 859, 
860) . In either case, the send customer routine returns 
to the event subtask (826), which reads the next activity 
from the activity table. 
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After the activity for sending customer records 
(by selected status) has executed, the next activity 
specified in the Event Table is for sending negative 
status records (both NEGATIVE and CASH ONLY status). The 
corresponding, routine in the event subtask for executing 
the send negative status record activity operates 
identically .to the send customer record routine (850) in 
retrieving negative status records accessed during the 
current global update event interval from the negative 
status file and sending those records to the host. 

After negative status records have been sent, 
the receive customer records and negative status records 
activities, are executed. Because of the essential 
transparency ,of^the remot ^^^i^^^i^^^^ ons °P eration 
using the vp&t/remote. theeeceive activity is 

analogous to the send activity. The rejpote receive^record 
activity ^routine requests records Trora the ho^tBWf. The 
^ host^awrespon3s^^^^gloMlly updated records that are. 
sent by the remote routine to the remote DMT for remote 
global update. 

When the last send/receive activity for the 
global update function at the current event time has been 
completed (i.e., the last receive negative status record 
routine has 

from the hbs^®MT^to tXe remote BM^jor global /update) 
that routine returns to the event subtask, which 
determines that the current event time contains no more 
activities to be executed (826) so that the activity 
sequence is complete (828). -The event subtask then checks 
the modem flag (870) to determine whether any 
communications link is active. In the present description 
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of an exemplary operation of the event subtask to execute 
a global update function, the originate call routine (840) 
connects to the host and sets the event subtask modem flag 
(846). 

Accordingly, at the completion of the activity 
sequence for the global update function, the event subtask 

flag is set (870) and requests the 
from the host. The event subtask 
monitors its semaphore flag (873) until notified by the 
remote MMT that the communications link to the host has 
been terminated. When the semaphore flag is set, the 
event subtask clears (874) the modem flag, and then clears 
(876) the event active semaphore in the Event Manager 
Task. Finally, the event subtask (a) calculates the new 
event time for the event record based on the event 
interval and writes it into the event record, and 
(b) writes the current event time into its control data 
block for access during the. next event/activity execution. 

If the event siibtask had been executing an event 
time and associated activity sequence in which ■ 
communications was not necessary, such as backup or purge, 
the event subtask detects that the modem flag is clear 
(870). In that case, the event subtask would immediately 
clear, the event active semaphore (876) and terminate 
(878). 

3.6 Modem Manager Task . The Modem Manager Task 
manages modem communications, primarily to support 
host/remote file transfer for global update, but also for 
remote diagnostic purposes. Operation for host/remote 
file transfer depends in part upon whether the modem 
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manager task is running in the host or remote check 
transaction processing system all host/remote file 

transfers are initiated and controlled by the remote 
system. 

Modem communications through the Modem Manager 
Task are essentially transparent to the other tasks, 
functionally operating as an extension of the normal 
intertask communications using intertask service requests. 
Thus, the remote Event Manager Task sends service requests 
to the host Data Manager Task through^ the remote System 
Kernal, the remote Modem Manager Task, the host Modem 
Management Task and finally the host System Kernal. 
Similarly, the host Data Manager Task responds with a 
reply, including response data and, a stop request, over 
the same host/remote communications path. 

For remote-to-host file transfers, the remote 
Event Manager Task first issues a. dial host request to the 
remote Modem Manager Task, which the Modem Manager Task 
executes by dialing the host Modem Manager Task and 
detecting an off-hook condition at the host. When the 
remote Event Manager Task is notified by a s ^S£^ ema V^S££ a ^ 
that a connection has been made, it 'requests ^tneS^^to 
send a Log- In ID to establish an active communications 
link- The remote Event Manager Task then issues a service 
request to the host Data Manager Task, which is directed 
by the remote System Kernal into the Modem Manager Task 
queue. The Modem Manager Task reads the request and sends 
it to the host system, where the host Modem Manager Task 
transfers the request to the host Data Managgr Task > 
throuah the host System Kernal . The host y^ fata manag e! 
i4s^yresponds with a reply that includes a stop request 



this response is communicated through the host/remote 
Modem Manager Task link to the remote Event Manager Task. 

At system initialization, the Modem Manager Task 
opens its communications port, and conducts modem start-up 
diagnostic tests. 

FIGURE 12 is a program flow diagram for the 
Modem Manager Task. The task continually monitory ( 902 ) 
its task queue to detect either (a) intertask request 
packets written into the queue by the System Kernal, or 
(b) a ring indication. When an intertask request packet 
is written into the Modem Manager Task queue, the Task 
reads the packet, and decodes the function code and 

dispatches the request to an appropriate modem 

control routine: Dial, Send, Disconnect and Reset. A 
communications session will always be initiated with a 
Connect request directed to the Modem Manager Task, which 
executes the request by dialing the number specified by 
the request data (typically the host), and in conjunction 
with the host Modem Manager Task, establishing a line 
connection between the two systems. 

Typically, when the remote Event Manager Task is 
advised (with a stop semaphore) by the Modem Manager Task 
that the host answered the call and a line connection is 
made,. the Event Manager Task sends, via the Modem Manager 
Task a Log- In ID that establishes an active communications 
link between the two systems. Once an. active 
communications link is established/ the remote/host file 
transfer procedure for communicating negative status and 
customer records is as follows. 

The remote Event Manager Task sends a request 
for global update of a record to the host Data Manager 



Task, writing the record into a specified request data 
location. The remote System Kernal builds an intertask 
request packet, and routes it to the remote Modem Manager 
Task. The Modem Manager Task reads (920) the request data 
from the location specified in the intertask request 
packet, and builds (922) a corresponding communications 
packet, including both the request and the request data. 
The communications packet is sent (924) to the host Modem 
Manager Task, t and the remote Modem Manager Task waits for 
a reply. 

When the Modem Manager Task receives (926) a 
reply from the host, which includes both response data 
(such as an acknowledgement^ and stop request, the 
response data is written (M8) to the specified location 
for response data, and the stop request is sent (929) to 
the System Kernal, which sets the appropriate semaphore 
flag. 

This communication procedure is continued so 
long as requests are sent to the Modem Manager Task (920). 
A remote/host file transfer session is terminated by the 
remote Event Manager Task sending to the remote Modem 
Manager Task a disconnect request (916). 

The host and remote Modem Manager Tasks 
cooperate to establish a communications link as follows. 
A communications session is initiated by a dial request 
from the remote Event Manager Task is directed to the 
remote Modem Manager Task, which reponds by dialing the 
host. 

A ring indication at the host modem is detected 
(908) by the host Modem Manager Task, which directs the 
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modem into an off-hook condition (930),. establishing a 
remote/host connection. 

The remote Event Manager Task then sends an 
appropriate log-in identification (932). 

File transfer communications are commenced when 
the host Modem Manager Task receives (934) a 
communications packet from the remote Modem Manager Task. 
The host Modem Manager Task builds (936) a corresponding 
service request that is sent (938) to the host System 
Kernal. 

The service request is directed to the 
designated responding task, such as the host Data Manager 
Task, which executes the request and provides both 
response data and a stop request. The host Modem Manager 
Task reads (940) the stop request from its queue, and 
reads (942) the response data from the specified location. 

The host Modem Manager Task then builds (944) an 
appropriate reply packet (including the response data and 
the "stop" request), and sends (946) the reply to the host 
Modem Manager Task. The next communication to the host 
Modem Manager Task will either be a Disconnect instruction 
(948) or another commnications packet. 

The Modem Manager Task implements remote/host 
communications functions in a manner that is essentially 
transparent to the other tasks and the System Kernal. 
That is, intertask communications between a remote task 
and a host task are accomplished in a manner identical to 
intertask communications between tasks running in the same 
check transaction processing system, except that both the 
remote and the host System Kernal are involved in the 
intertask communication, as are the remote and host Modem 
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Manager Tasks. HewevHT7~~-tte — Gommuni«atio&s — £\±n&E*&i* 
provided by the remote and host Modem Manager Task^/is 
essentially transparent to the other tasks running in 
either the remote or the host. For example, t|>e remote 
event subtask sends requests in the form of service 
requests to the. host Data Manager Task just as it would 
send requests' to the remote Data Manager Task. 
Specifically, the remote event subtask/builds a request to 
the host DMT, and sends the service /request to the remote 
System Kernal. The remote Sys£em/kernal builds a inner 
task request packet and places i^t )in the remote MMT task 
queue. The remote MMT task Wajds the intertask request 
packet and builds a communi^atyixns packet for the request 
to the host DMT (includinc/ functibn-c^de, request data and 
stop semaphore flag). /The /remote MMT transmits the 
communications packet /to. We host MMT, which builds a 
corresponding servicer request for the host System Kernal. 
The host System Kernal builds an intertask request packet 
that is placed in/the host DMT task queue. The host DMT 
retrieves the Intertask request packet, which constitutes 
a request fronrt the remote event subtask, and executes it 
in the same/manner that it would a request from the host 
event subtask, writing response data into the specified 
response/data location and sending a stop request to the 
host system Kernal. The host System Kernal, recognizing 
the sxop request as being directed to the remote event 
subtfask, builds an intertask packet with both the response 
data and the stop request and writes . into the remote MMT 

^ £he — remote..-MMT -reads "the "intertask request 

Ipacket^— bu-3rld y a cum murri-^-a ti o n s - p a cke£_and sen ds it to the - 
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rpjrnrv^^ MMT ■ The r-e-Hve^e — MMT— wr i t es — th e -r esp onse -dat-a— i-n^to — 

a specified location in the data area for the Event 
Manager Task, and sends the op Hre quest to> the remote 
System Kernal. The remote System^. Kernel sets the 
specified stop semaphore, /notifying the remote event 
subtask that response data from the host DMT is available, 
completing the request/response cyd o . 

4.4. Alternative Embodiments 

While the check transaction processing system 
has been described in connection with a preferred 
embodiment, other embodiments within the spirit and scope 
of the invention as defined by the following claims will 
be apparent to those skilled in the art. 

For example, in the case of multiple-store 
systems, the preferred embodiment includes separate, 
essentially autonymous check transaction processing 
systems at each store site, thereby permitting each store 
to establish and maintain an essentially local customer 
database, and limiting off-site data communications 
activities to remote/host file transfers for global 
update. However, the local customer database (and 
associated disk system) need not be located at the store 
site, but may be remote 'from the stores' transaction 
terminal network (such as by locating it in a central 
office) so long as: (a) transaction terminal response 
time is not adversely affected and, (b) the essentially 
local character of the customer database for each is 
maintained. 

The preferred embodiment's implementation of a 
multitasking system using a System Kernal for 





115 



task-switching and intertask communications, can be 
readily adapted to operate under a commercial, 
multi-tasking operating system. These operating systems 
provide the task switching and intertask message 
communications functions performed by the System Kernal. 
Adapting the CTPS multi-tasking program to a commercially 
available multi- tasking operating system is well within 
the programming capabilities of those skilled in the art. 
Each program task would be modified in a conventional 
manner to accomodate the specific message communication 
function implemented by the multi-tasking operating 
system. 
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TABLE 1 

CUSTOMER RECORD SPECIFICATION 



Field Name 

char id 
char status 



char flags 

long curr date 
long last date 
long statdate 

int hi tent 
char hitfreq 

long amtfreq 

long amount 

long totamt 

long date 



Description 

customer. 1 s bank id 
current status (CAUTION, 
NEGATIVE, POSITIVE, CASH 
ONLY, STOLEN) 

id user flags [PREAPPROVE, 
MANAGER ONLY] 
last access date 
last transfer date 
date status changed 

local total hit count 

local hit -count frequency, 

previous 7 days 

iocal amount frequency, 

previous 7 days 

local last dollar amount 

verified 

local total dollar amount 
verified 

local access time 



int hi tent 
char hitfreq 

long amtfreq 



global total hit count 
global total hit count 
frequency, previous 7 days 
global amount frequency, 
previous 7 days 



long amount 

long totamt 

long date 

char status 

int lhitcnt 
long ltotamt 
int ghitcnt 
long gtotamt 
long statdate 

int hi tent 

long totamt 



global last dollar amount 
verified 

global total dollar amount 
verified 

global access time 

previous status before 
current 

previous local hit count 
previous local dollar amount 
previous global hit count 
previous global dollar amount 
previous status date 

total hits since last 
transfer 

total dollars since last 
transfer 
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TABLE 2 

NEGATIVE STATUS RECORD SPECIFICATION 



Field Name 



Description 



char id 
char COlocid 
char Nlocid 
char Nstatus 

CHAR COstatus 

long currdate 
long COstatdate 
long Nstatdate. 
int hitcnt 

long totamt 



customer 1 s bank id 
location showing CASH ONLY 
location showing negative 
current record status 
NEGATIVE 

current record status CASH 
ONLY 

current access date 

■I 

date became CASH ONLY 
date became negative 
total bad checks against 
location 

total bad dollars against 
location 
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TABLE 3 

SYSTEM CONTROL FILE SPECIFICATION 



Field 

int hitcnt 
long amount 
Vf yLimit 



Definition 

hit count limit 

dollar amount limit 



char locid 



system id 



int port 
int pollcnt 
int recvcnt 
keypad 



keypad comm port 

keypad poll counter limit 

kaypad poll receive limit 



int port 
char tone 
modem 



modem comm port value 
tone/pulse dial mode 



long strttime 

long currtime 
char errfile 
char loggile 
char password 
char flags 
sysinf o 



system start time (machine 

turned on) 

current system time 

error filename 

screen log filename 

system access password 

system control flags 



char dayflag 



flag for day/second roll 
limits 
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long ctnroll 
long ctnlim 
long neglim 
long poslim 
long colim 
long sclim 
database 

VfyLimit dmax 

•VfyLimit wmax 

VfyLimit tmin 



caution to positive limit 
caution purge limit 
negative purge limit 
positive purge limit 
cashonly purge limit 
stolen purge limit 

day maximum call manager 
limits 

week maximum call manager 
limits 

total minimum call manager 
limits 



callmgr [ 5 J 
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TABLE 4 
FUNCTION CODE SPECIFICATION 



Function: 
Description: 

Keypad Input: 
Keypad Output: 



Fl 

Query ID, displaying current 

data 

[id] Fl 

Status Dhitcnt Whitcnt 
Thitcnt 

$totamt StatDate ID 



Function: 
Description: 

Keypad Input: 
Keypad Output: 



F2 

List Negative Locations for 

entered ID 

[id) F2 

NEG LOCATIONS 

LOCI L0C2 LOC3 . . . LOC10 



Function: 
Description: 

Keypad Input: 



Keypad Output: 



F3 

Query Negative location ID as 
found on F2 
[id] F3 $n 

*n - LOCn as shown on F2 

display 

Neg Inquiry 

LOCn Thitcnt $totamt negdate 




Function: 
Description: 
Keypad Input: 
Keypad Output: 

Function: 
Description: 

Keypad Input: 
Keypad Output: 



Function: 
Description: 
Keypad Input: 
Keypad Output: 

Function: 
Description: 
Keypad Input: 
Keypad Output: 

Function: 
Description: 
Keypad Input: 
Keypad Output: 
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F4 

Query Location ID 
[id] F4 
LOC locid 
locname 

F5 

Query ID Hitcounts and Dollar 

Amounts 

[id] F5 

Status Dhitcnt; amount 
Whitcnt; amount Thitcnt; 
amount 

F40 

Add Cashonly ID 
id F40 

CASH ONLY FILE 
id 

F41 

Add Stolen ID 
id F41 
STOLEN FILE 
id 

F42 

Add Preapproved ID 
id F42 
PREAPPROVED 
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Function: 
Description: 
Keypad Input : 
Keypad Output 

Function: 
Description: 
Keypad Input: 
Keypad Output 



F43 

Add Manager Only 
id F43 

MANAGER ONLY 
id 

F44 

Add Negative ID with location 
id F44 

NEGATIVE FILE 
id 
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Function: 
Description: 

Keypad Input: 
Keypad Output: 



F55 

Verify ID. If F55 is not 
included, verify is assumed 
id [F55] 

*if any limits are exceeded: 

CALL MANAGER 

id 

*status is caution: 
CAUTION hi tent 
id 

*status is negative: 

NEGATIVE 

id 

*status is positive: 

POS Dhitcnt Whitcnt Thitcnt 

id 

*status is cashonly: 

CASH ONLY 

id 

*status is stolen: 

STOLEN 

id 



Function: 
Description: 
Keypad Input: 
Keypad Output: 



F60 

Delete Cashonly ID 
id F160 

CHECKS ACCEPTED 
id 
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Function: 
Description: 
Keypad Input: 
Keypad Output: 

Function: 
Description: 

Keypad Input: 
Keypad Output: 

Function: 
Description: 

Keypad Input: 
Keypad Output: 

Function: 
Description: 
Keypad Input: 
Keypad Output: 

Function: 
Description: 
Keypad Input: 
Keypad Output: 



F61 

Delete Stolen ID 
id F61 

CHECKS ACCEPTED 
id 

F66 

Add Positive ID. Remove 
stolen list 
id F66 

PAID OFF FILE 
id 

F77 

Login to system to gain 
access to privileged commands 
id F77 
Login Valid 
Begin Session 

F62 

Delete Preapproved 
id F62 
PREAPPROVED 

F43 

Delete Manager Only 
id F63 

MANAGER ONLY 
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Function: 
Description: 
Keypad Input: 
Keypad Output: 

Function: 
Description: 

Keypad Input: 
Keypad Output: 

Function: 
Description: 

Keypad Input: 
Keypad Output: 

Function: 
Description: 
Keypad Input: 
Keypad Output: 



F88 

Logout from system 
F88 

End Session 
Bye! 

F900 

Return System Author 

Information 

F900 

CVS V4.20 (c) 1989 CVC, by 
Scott Wood, CCP 

F901 

Return System Internal Date & 

Time 

F901 

System Date 
mm/dd/yy - hh:mm:ss 

F902 

Return System Memory Usage 
F902 

System Memory 
b Bytes Free 
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Function: 
Description: 
Keypad Input: 

Keypad Output: 

Function: 
Description: 
Keypad Input: 
Keypad Output: 

Function: 
Description: 

Keypad Input: 
Keypad Output: 

Function: 
Description: 

Keypad Input: 
Keypad Output: 



F903 

Return Disk Usage 
n F903 

*n - 3 = Drive C 
*n - 4 - Drive D 
Disk Usage (CID) 
Bytes: n Total, n Free 

F904 

Return ID Database Size 
F904 

ID Database 
n Records 

F905 

Return Negative ID Database 

Size 

F905 

Negative dBase 
n Records 

F906 

Return System Information 
depending on n 
n F906 

*n-0 - System ID 

Location ID 

locid 
*n=l - Keypad Data 

Keypad Info 

Port:n, Poll:n, Recv:n 
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*n=2 - Modem Data 
Modem Info 
Port 0:11, Port l:n 
*n=3 - System Start Time 
Start Time 
mm/dd/yy - hh:mm:ss 
*n=4 - System Current Time 
Current Time 
mm/dd/yy - hh:mm:ss 
*n=5 - System Password 
Password 
passid 
*n=6 - t System Flags 

Flags n 
*n=7 - Caution Roll Period 
Caution Roll 
n seconds 
*n=8 - Caution Purge Limit 
Caution Limit 
n seconds 
*n=9 - Negative Purge Limit 
Negative Limit 
n seconds 
*n=10 - Positive Purge Limit 
Positive Limit 
n seconds 
*n=ll - CashOnly Purge Limit 
CashOnly Limit 
n seconds 
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*n-12 - Stolen Purge Limit 
Stolen Limit 



*n=13 - Caution Call Manager 
Limits 

Caution Callmgr 
Dhi tent, amount - 
Whi tent, amount - 
Thitcnt, amount 
*n=14 - Negative Call Manager 
Limits 

Negative Callmgr 
Dhi tent, amount - 
Whi tent, amount - 
Thi tent , amount 
*n=15 - Positive Call Manager 
Limits 

Positive Callmgr 
' Dhitcnt, amount - 

Whi tent, amount - 

Thitcnt, amount - 
*n=16 - Cashonly Call Manager 

Limits 

Cashonly Callmgr 
Dhitcnt , amount - 
Whi tent, amount - 
Thitcnt, amount - 
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Function: 
Description: 
Keypad Input: 

Keypad Output: 

Function: 
Description: 

Keypad Input: 

Keypad Output: 

Function: 
Description: 

Keypad Input: 
Keypad Output: 



*n=17 - Stolen Call Manager 
Limits 

Stolen Callmgr 
Dhi tent, amount - 
Whi tent, amount - 
Thi tent, amount - 

F940 

Toggle Screen Logging 
n F940 

*n=0:0ff, l:On 
Screen Log 
(ON | OFF) 

F950 

Start Event Activity for 
event n 

n F950 [mmddmmss] 
*n=event number 
Event n 
Stopped 

F951 

Stop Event Activity for event 
n 

n F951 
Event n 
Stopped 
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Function: 
Description: 

Keypad Input: 

Keypad Output: 

Function: 
Description : 

Keypad Input: 

Keypad Output: 

Function: 
Description: 
Keypad Input: 

Keypad Output: 

Function: 
Description: 

Keypad Input: 
Keypad Output: 



F952 

Get Event Activity for event 
n 

n F952 

*n=event number 
mm/dd/yy - hh:mm:ss 
actl act2 act3 . . . actio 

F953 

Get Activity Status for 
activity n 
n F953 

*n=event number 
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WHAT IS CLAIMED IS : 

\7 A check -transaction processing system" using 
iu^tome/s checking account identification number as a 
unique customer identification code/ ("check ID") 
comprising: 

a transaction processor fox processing check 
transactions for a store, and for /storing a customer 
database, including customer recordyfe, for that store; 

each customer record bei/ng uniquely identified 
by the customer's check ID, a/d including selected 
customer information; 

said customer information including check 
verification status information/ such that a customer is 
assigned one of the following yfcheck/verif i cation status 
values: 

POSITIVE -/ //he customer's check 
transaction hisyory meets preselected positive 
criteria for authorizing the check transaction; 



NEGATIVE ' 



the customer's check 



transaction history meets preselected negative 
criteria for not authorizing the check *\ 
transaction/; or 

CAUTION — the customer's check transaction 
history meets neither the positive or negative 
criteria/ so that authorization of the check 
transaction depends upon predetermined interim 
criter/a. 'i 
said /customer information including check 
transaction daxa about the customer's check transaction 
historyj^Vncl^uding frequency and dollar volume over 
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^^hich is Updated for each check 



selected intervals)! 
transaction to reflect the current check transaction. ~j I 

at least one transaction terminal located at a 
point-of-sale and remotely coupled to said transaction 
processor for transmitting customer information requests 
to, and receiving customer information responses from, 
said transaction processor; 

each customer information request including the 
customer's check ID and a function code identifying the 
information requested; 

one of the custonJerjy^jpfcormsit ion- request function 
codes designating a check transaction verification 
function in which the cor/responding customer information 
response is used for chec« transaction authorization. 

said (transaction processor processing each 
customer information reoAiest by: 

retreiving the corresponding customer 
record, if it exists. in the customer database; 
and I' 

generating a customer information response 
in accordance with the function code in the 
customer information request, reflecting either 
the customer information in the. customer record, 
or the absence of such a customer record in the 
customer/ database . 
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2. The check transaction processing system 
defined in Claim 1, wherein: 

the CAUTION status designates an interim status 
after the customer's first check transaction, which lasts 
for a period of time defined/by a CAUTION/POSITIVE limit; 

the CAUTION status being automatically changed 
to a POSITIVE status upon tfhe occurrence of preselected 
CAUTION/POSITIVE criteria. 

3. The check t/ran»action processing system 
defined in Claim 2, whereiii if a check transaction meets 
preselected transactional irite^iabased on the customer's 
check transaction historj, ItAe response to a customer 
information request for/ check verification is a 
conditional response, regardless of the check verification 
status indicated in the dustomer record. 



4. The check transaction processing system 
defined in Claim 3, U wherein said predetermined 
CAUTION/POSITIVE criteria comprises no bad checks being 
received for the customer during said CAUTION/POSITIVE 
period. 



5. The cWeck transaction processing system 
defined in Claim 4J wherein a POSITIVE status is 
automatically changeJd to a CAUTION status if the 
transaction interval between a customer's check 
transactions exceed;/ a preselected reset/CAUTION limit. 



\ 



137 



6. The check transaction processing system 
defined in Claim 5, wherein 

said transaction^processor is coupled by a 
communications link to/at/ least one other transaction 
processor in another srto 

said other 
check transactions, a 1 
such other store; 

said transaction processors communicating, at 
preselected intervals,/ preselected global customer 
information between the stores. 



feactfon processor processing 
ring a customer database, for 




\ 
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A check verification r/ethod, comprising the 



storing check transaction^ information relative 
to a plurality of customers; 

said transaction information including a 
positive indicator indicating a /customer has previously 
fulfilled predetermined check transaction criteria; 

said check transacting nf ormation including a 
negative indicator indicaVinA at customer has not 
successfully fulfilled /sai/l predetermined check 
transaction criteria; 

said check triinsa'cti'on Wn^rmation further 
including a provisional /ind/ca^or .indicating insufficient 
data as tp -whether or Lot/ a/ customer has successfully 
fulfilled said prede^rrUnec/ check transaction criteria; 

said check \± Transaction information further 
including check' transaction frequency and check 



transaction dollar amount 
intervals; 



for a customer over selected 



placing prideteir^nined limits on check 
transaction frequency and dollar amounts over 
predetermined intervals for a customer with a positive 
indicator, in dependence upon the customer's continuing 
check transaction ha story; 

automatically changing said indicator status for 
each customer in dependence upon the customer's continuing 
check transaction history. 
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